EXAMENSARBETE INOM DATATEKNIK, GRUNDNIVÅ, 15 HP STOCKHOLM, SVERIGE 2021

Mobile cross-platform gesture- guided visual pain tracking for endometriosis

ALFIO BRANCOZZI

KTH SKOLAN FÖR ELEKTROTEKNIK OCH DATAVETENSKAP i

Abstract

Rapid growth in mobile technologies since the 2000s is reflected in continued smartphone adoption and the expansion of mobile health (mHealth) smartphone applications for pain assessment. Yet there exists a lack of research-based pain assessment apps for endometriosis, a prevalent yet underrepresented disorder where pain management plays a vital role. The predominance of the iOS and Android smartphone operating systems has previously required developers to maintain two separate codebases and development environments in order to access a combined 99% market share. Since 2015, cross-platform development softwares have allowed for maintenance of a single codebase and environment. This thesis explores the development of a cross-platform smartphone app for endometriosis pelvic pain assessment where design decisions are informed by endometriosis and pain assessment research as well as engineering particularities of the React Native framework. The completed prototype along with this thesis’ design discussion indicate that research findings into endometriosis pain assessment can be successfully adapted via React Native into a visual, gesture- guided functionality for the self-assessment of endometriosis related pelvic pain.

Keywords mHealth, smartphone, endometriosis, pain, React Native, gesture, symptom tracking

iii

Sammanfattning

Den snabba tillväxten inom mobilteknik sedan 2000-talet återspeglas i en fortsatt ökning av smartphone-användare samt utvidgningen av mobilhälsoapplikationer (mHealth) för smärtbedömning. Ändå finns det en brist på forskningsbaserade smärtbedömningsappar för endometrios, en vanlig men underrepresenterad sjukdom där smärtlindring spelar en viktig roll. Övervägande av operativsystemen iOS och Android har tidigare krävt att utvecklare underhåller två separata kodbaser och utvecklingsmiljöer för att få tillgång 99% av marknaden. Sedan 2015 har mjukvaror för plattformsoberoende utveckling av mobilapplikationer möjliggjort underhåll av en enda kodbas och miljö. Denna avhandling undersöker utvecklingen av en plattformsoberoende applikation för smarttelefoner för utvärdering av bäckenvärk relaterade till endometrios, där designbeslut baseras på forskning om endometrios och smärtbedömning samt tekniska särdrag i React Native-ramverket. Den färdiga prototypen tillsammans med avhandlingens designdiskussion indikerar att forskningsresultat kring bedömning av smärta i endometrios kan anpassas via React Native till en visuell, geststyrd funktionalitet för självbedömning av endometriosrelaterad bäckenvärk.

Nyckelord mHealth, smartphone, endometrios, smärta, React Native, gest, symptomspårning

v

Table of Contents

Abstract ...... i Keywords ...... i Sammanfattning ...... iii Nyckelord ...... iii Table of Contents ...... v 1 Introduction ...... 1 1.1 Project background ...... 1 1.2 Research background and problem statement ...... 2 1.3 Purpose statement ...... 2 1.4 Research methodology and methods ...... 2 1.5 Project methodology and methods ...... 3 1.6 Delimitations ...... 3 1.7 Structure of the thesis ...... 3 1.8 Source code ...... 3 2 Literature Review ...... 5 2.1 Clinical research considerations ...... 5 2.1.1 Endometriosis and endometriosis-related pain ...... 5 2.1.2 Pain measurement research and pain scales ...... 6 2.1.3 Pain assessment for endometriosis ...... 8 2.2 Related research-informed software ...... 9 2.2.1 Computerised pain body maps ...... 9 2.2.2 mHealth for endometriosis ...... 11 2.3 Engineering considerations ...... 11 2.3.1 JavaScript, JSON and NodeJS ...... 11 2.3.2 React Native and React design principles ...... 13 2.3.3 React Native architecture ...... 14 2.3.4 React Native animation and gesture handling ...... 15 2.4 Summary of findings ...... 17 3 Methodology and Methods ...... 19 3.1 Research methodology and methods ...... 19 3.1.1 Case study methodology ...... 19 3.1.2 Action research methodology ...... 19 3.1.3 Characteristics of research methodologies ...... 20 3.1.4 Adapted research methodology ...... 23 3.1.5 Research method ...... 24 3.1.6 Research evaluation ...... 24 3.2 Project methodology and methods ...... 26 3.2.1 Agile, Lean, and adapted project methodology ...... 26 3.2.2 MoSCoW analysis ...... 26 3.3 Development environment...... 27 3.3.1 Expo...... 27 3.3.2 Environment setup ...... 27 3.3.3 Manual testing ...... 27 vi

4 Results ...... 28 4.1 Software requirement definition ...... 28 4.2 Research-informed application features ...... 30 4.2.1 Prototype overview ...... 30 4.2.2 CPBM design ...... 31 4.2.3 Daily tracking and calendar...... 32 4.2.4 Pain types ...... 32 4.2.5 Pain intensity scale ...... 34 4.2.6 Pain frequency ...... 34 4.2.7 Factors ...... 35 4.2.8 Bleeding scale ...... 35 5 Discussion and Conclusion ...... 37 5.1 Reliability and validity of methods and results ...... 37 5.2 Reliability and validity of data ...... 37 5.3 Research outcomes ...... 37 5.4 Limitations and future work ...... 38 References ...... 39 Appendix: Code highlights ...... 43 Screen navigation...... 43 Draw UI state ...... 44 Canvas implementation ...... 44 Gesture handling ...... 46 Stroke data model and styling ...... 48 Factors data model and styling...... 50 Persistence ...... 50

1

1 Introduction

Mobile health (mHealth) is the use of wireless mobile technologies for supporting individuals’ wellbeing in medical and public health practice [1]. It has expanded rapidly since the early 2000s in countries surveyed by the World Health Organization, with 80% of low-income and 91% of high- income countries reporting at least one public mHealth initiative as of 2017 [2]. Ongoing adoption of smartphones worldwide [3] has allowed for an evolution in the sophistication of mHealth services from simple text messaging and automated phone calls to multi-feature applications. Smartphone health apps are a rapidly growing category of mHealth: over 318,000 were available from app stores with an estimated 200 being added each day in 2017 [4]. One subset of health apps aims to support individuals in their management of pain, often in the context of a particular diagnosis or treatment- related scenario such as cancer or post-operative monitoring. One 2015 study identified 901 pain- related smartphone apps available for download across various app stores [5].

The two predominant mobile operating systems today are iOS and Android, with a respective 28% and 71% of market share as of 2020 [6]. The iOS and Android development environments are vastly different, and app developers wishing to access their combined 99% market share have traditionally been required to maintain two separate environments and codebases for each app. Consequently, software packages self-styled as ‘frameworks’ or ‘software development kits’ have emerged that enable the development of cross-platform versions of apps from a single code base and development environment. This is achieved via implementation of custom runtime environments that can interface with platform-specific or ‘native’ APIs while executing ‘non-native’ code.

This thesis focuses on the development of an mHealth cross-platform smartphone pain tracking functionality for use in the context of a suspected or confirmed diagnosis of endometriosis. Endometriosis is a painful disorder involving abnormal growth of hormonal tissue within the body that affects a significant population worldwide yet is relatively underdiagnosed and unrecognized even among medical professionals. An absence of effective non-invasive medical diagnostic methods or treatments leaves pain assessment as the most accessible method for diagnosing and managing endometriosis. Yet despite rapid growth in mHealth smartphone apps, there are few research-based examples targeted to tracking pain in an endometriosis context.

1.1 Project background

Endometrix is a health tech start-up that aims to improve the quality of life for those with a confirmed or suspected diagnosis of endometriosis. The cross-platform framework React Native is used by the Endometrix development team for the efficiency of being able to develop for both iOS and Android from a single codebase and development environment.

In the Endometrix mobile app, users can track a range of variables to gain insights into the patterns of their disorder and to share data with healthcare providers to assist with diagnosis and symptom management. Pain is measured in the app with a 1-100 scaled slider labelled ‘Overall pain’ accompanied by optional descriptive tags that indicate qualitative aspects of pain such as location, duration and intensity. 2

There is an opportunity to deepen user experience and add value to the Endometrix app by further developing the existing pain tracking functionality to better exploit the capabilities offered by mobile smart devices. This has led to the idea of developing a visual representation of endometriosis- related pain in the body which can be manipulated via smartphone touch interfaces.

1.2 Research background and problem statement

There exists medical and information systems research about the design, use and effectiveness of both mobile and non-mobile applications for recording and communicating pain. Computerised Pain Body Maps (CPBMs) are an area of research concerned with drawing pain within body models on digital interfaces, and there are mobile apps currently available that offer a gesture-guided pain drawing functionality.

However, there is a research gap from a software engineering perspective in documenting how such functionalities are developed. Another research gap exists in examining how CPBM development decisions are influenced by the context of a suspected or confirmed diagnosis of endometriosis. The research focus can be further narrowed by limiting scope to only pelvic-related pain which leads to the research question:

How can a cross-platform, visual, gesture-guided and research-informed mHealth application for measuring pelvic pain associated with endometriosis be developed?

1.3 Purpose statement

The thesis of this degree project aims to contribute to research at the intersection of endometriosis, pain assessment, mHealth and software engineering by presenting and discussing a design solution tailored to the specific context of pelvic pain connected to endometriosis. This contribution can potentially benefit future researchers interested in questions involving mHealth software tailored to endometriosis-related pain.

The purpose of the degree project itself is to deliver a new pain assessment functionality that can complement or replace the existing slider-based functionality in the Endometrix app. It is anticipated that users will benefit by having access to an additional tool that is potentially more effective than a slider in recording and communicating pain. Endometrix also stands to benefit from the added value this new functionality could potentially bring to the app.

1.4 Research methodology and methods

Thesis methodology is described as a process-descriptive case study informed by a preliminary literature review. It incorporates concepts from Case study and Action research methodologies, two of five ‘classes’ of software engineering research methodologies described by Easterbrook et al. [7]. Knowledge obtained from the literature review is used as a starting point for guiding iterative cycles of research and development. The method of data collection shall be documentation of software requirements and with resulting features and their underlying source code source, which will inform 3 the presentation and discussion of results. The functioning prototype created from the development process serves as an evaluating example of the results, certified by a rigorous manual testing process.

1.5 Project methodology and methods

Project methodology is described as a hybrid of Agile and Lean software project methodologies and uses MoSCoW method to prioritize development goals. The relatively small nature of the project does not suit more sophisticated, Agile-influenced software project methodologies that promote responsive collaboration between teams, such as Scrum and Kanban. Instead, certain Agile and Lean concepts are adopted together with the use of MoSCoW analysis to guide software development.

1.6 Delimitations

This thesis answers a research question at the intersection of endometriosis, pain assessment and software engineering by detailing a cross-platform software solution. It does not attempt to present new research findings on endometriosis as a disorder, the effectiveness of different pain measurement methods, the comparison between native and cross-platform development, or the comparison between different cross-platform development softwares. The effectiveness of the software solution is not researched in this thesis, this is the next logical research step as outlined in future work.

1.7 Structure of the thesis

Section 2 presents a literature review of the medical and software engineering knowledge required for development. Section 3 gives a brief overview of relevant methodologies and methods from a software engineering research perspective before introducing the adapted research methodology, research method, research validation and development design. Section 4 presents the major design features of code. Section 5 presents the results. Section 6 presents the discussion and conclusion.

1.8 Source code

The codebase for the prototype created from this thesis is available as an open-source repository on GitHub. The link to the source code is available in the appendix.

5

2 Literature Review

This chapter summarizes knowledge that informs the thesis research process and in doing so addresses the first research subquestion presented in section 3.1.5 (p. 24): “What existing knowledge can inform development of the described application?”. Section 2.1 covers clinical research into endometriosis and pain assessment that informs design decisions. Section 2.2 covers related instances of research-informed software. Section 2.3 covers engineering knowledge required to develop the application. Section 2.4 summarizes the findings of the literature review.

2.1 Clinical research considerations

This section covers clinical research that informs aspects of feature design. Section 2.1.1 introduces endometriosis and describes pain related to a diagnosis of endometriosis. Section 2.1.2 begins with a brief overview of modern research into pain measurement before narrowing focus to self-reported pain scales. Section 2.1.3 examines research at the intersection of pain measurement and endometriosis.

2.1.1 Endometriosis and endometriosis-related pain Endometriosis is a disorder characterized by the abnormal presence of tissue similar to the innermost lining of the uterus (endometrium) in organs of the body other than the uterus [8]. Abnormal tissue forms as endometrial glands or lesions resembling connective material (stroma-like lesions) and are most commonly found in the membrane that lines the abdominal cavity (peritoneal lesions), the ovaries (endometrioma) or in organs enclosed by the peritoneum (deeply infiltrating endometriosis), though in rarer cases are found in many other organs of the body [8][9].

Endometriosis is underdiagnosed and underrepresented despite an estimated 5-10% of uterus carriers of reproductive age suffering from the disorder [10][11]. It is also rarely diagnosed with individuals born without a uterus [12]. Accounts of endometriosis-like symptoms and features have been recorded since antiquity [13], and while the disorder was first formally differentiated in the 1920s [14], current knowledge of its development, evolution and connection to infertility and pelvic pain is still deficient due to a lack of funding and multidisciplinary expertise [15]. The causes of endometriosis are not definitively known, there is no cure, the removal of affected organs does not guarantee remission, and there are currently no effective non-invasive diagnostic methods. Consequently, average time to diagnosis in 10 surveyed countries is between 6.7 to 11.7 years [16][17], and it has been estimated to cost the US economy at least $18.8 billion and the UK economy £8.2 billion annually.

Common symptoms of endometriosis include chronic pelvic pain, painful menstruation (dysmenorrhea), painful intercourse (dyspareunia), painful bowel movements (dyschezia) and painful urination (dysuria) [18][19][20]. Pelvic pain manifests most often in the loins, lower abdomen, lower back and thighs [21]. Pain severity can vary widely between patients and is uncorrelated with disease severity [18]. Endometriosis appears to be responsible for chronic pelvic pain symptoms in more than half of confirmed cases [22]. 6

Sensation of pain can vary widely, for example from dull to sharp to throbbing, with some patients reporting burning and hypersensitivity [21]. Pain can be exacerbated by physical activity, often worsens over time and can change in sensation. Periods of particularly intense pain are dubbed ‘flares’ or ‘flare-ups’ [23]. Occurrence is unpredictable, and it can be either intermittent or continuous in relation to an individual’s menstrual cycle. The often metaphorical nature of endometriosis-related pain along with a lack of adequate assessment tools often frustrates its communication and comprehension [24]. A “small but significant” correlation between symptom frequency and lowered subjective wellbeing for endometriosis sufferers is asserted in one study by Rush et al. [25].

2.1.2 Pain measurement research and pain scales Chapman et al. [26] introduce a widely cited 1985 overview of pain measurement research by stating that progress in the field has been slow because pain is a complex perceptual experience that can be quantified only indirectly, a statement which holds true today as there are still no validated objective markers of pain that can be recommended for clinical use [27]. Four types of research procedures are identified by Chapman et al. for indirect quantification of pain that emerged from human studies in the 20th century: pain threshold definition, rating scale methods, magnitude estimation procedures and laboratory task performance measurement. Pain threshold research involves progressive stimulation of a human subject to identify a point on a continuum that separates painful and non- painful experience. A second point separating tolerable and non-tolerable pain can be identified to produce a pain sensitivity range between these two points. Rating scale methods ask subjects to rate an experienced stimulus on a structured, categorized scale which may or may not include a pre-pain range. Some scales attempt to be strictly quantitative (unidimensional), while others incorporate a qualitative aspect such as emotional or aversive effects of pain (multidimensional). Magnitude estimation attempts to elicit a mathematical relationship between different pain stimuli by deriving a unique power exponent for each stimulus that can be used to define relationships between stimuli. Human performance measurement observes changes in subject behaviour in the presence of various stimuli.

Of these four categories, performance measurement and rating scale methods have the widest adoption in clinical practice due to the relative ease of their administration and their complimentary nature: they are often performed in parallel. Performance or behavioural measurement in a clinical setting involves observation and/or self-reporting of patient activities that are quantified with respect to varying levels of pain. Rating scale methods are administered in a clinical setting for patients to either self-assessed pain itself or self-assessed pain relief offered by analgesic treatment.

As research on clinical self-assessed pain scales has progressed, more attention has been afforded to the measurement of pain itself over measurement of pain relief, as well as to the emotional and reactional components of experienced pain. A range of research-based self-assessed pain scales now exist to measure pain, with many aimed at a specific demographic or diagnostic context. Unidimensional scales are more widely adopted in a clinical setting over multidimensional scales despite arguments that they underestimate the complexity of pain experience [28] and confuse intensity with emotional aspects of pain [29]. This literature study identifies three general 7 unidimensional pain scales as having received the most research attention: Visual Analogue Scales (VASs), the Verbal Rating Scales (VRSs) and the Numerical Rating Scales (NRSs) [30][31][32].

VASs are presented graphically to the patient as a 100mm line on which they mark a vertical stroke, after which the millimetre distance from the left side of the line is measured, giving 101 discrete levels of pain. NRSs can be presented either verbally or graphically with patients either stating or marking a number on a discrete scale to convey ordinal levels of pain, alternate ranges with minimum values of 0 or 1 and maximum values of 10, 20 or 100 exist in various adaptations. Graphical representation can vary from a scaled line as in Figure 1 to numbers enclosed in boxes. VRSs can also be presented verbally or graphically and use ordinal adjectives, in some cases numbered, to classify increasing levels of pain. Adaptations of VRSs noted in research have 4, 5, 6, 7 or 11 increments.

Figure 1: Graphical comparison of NRS-11, VRS-4 and VAS. Adapted from [28]. One general multidimensional pain scale, the McGill Pain Questionnaire (MPQ), is relevant to this literature review due to significant research attention in both general and endometriosis-related contexts [33]. Its standard form is interview-administered and consists of four parts: a diagram with front and back views of a human model on which to draw areas of pain (a Pain Body Map or PBM), a Pain Rating Index (PRI), questions relating to the temporal nature of experienced pain, and questions answered using a Present Pain Intensity (PPI) scale.

The PRI is 78 pain descriptors organised into 4 subscales and 20 subclasses: sensory (subclasses 1–10), affective (subclasses 11–15), evaluative (subclass 16), and miscellaneous (subclasses 17–20) [34]. Each subclass is an ordinal scale of 2-6 words with corresponding point values, subclass scores are summed per subscale to give 4 subscale scores. For the temporal aspect of pain, patients are asked to select one or more of nine descriptors grouped into three occurrence patterns: continuous, intermittent and transient before being asked to specify in their own words what alleviates and aggravates their pain. The PPI scale is similar to the VRS in that it attributes a 1-5 score to five ordinal adjectives (mild, discomforting, distressing, horrible, excruciating) and is used to answer 6 questions relating to pain intensity. A short-form adaptation (SF-MPQ) also exists consisting of 15 words organised under 2 subscales and 2 subclasses, a one-questions PPI, and a VAS [35][34]. 8

Much research exists studying the effectiveness of unidimensional pain scales for measuring pain in various contexts. VASs receive the most research attention due to their apparent precision and simplicity, however it is noted that most patients do not discriminate intensity with precision beyond 9 or 10 levels [30], often rounding to the nearest multiple of 5 or 10 [36]. The 0-10 NRS (NRS-11), the most used of its class, is thought to have adequate enough specificity [37] and good performance in its central 2-8 range [38]. Hjermstad et al. conclude a systematic literature review of pain scales stating that the VAS, NRS-11 and VRS-7 all perform well in different contexts and that the correct choice these depends on the conditions of its use [30].

2.1.3 Pain assessment for endometriosis In a systematic literature review Bourdel et al. identify 9 scales used in the assessment of endometriosis-related pain, the four most prevalent being VASs, VRSs, NRSs and the endometriosis- specific Biberoglu & Behrman (B&B) scale [39]. The 0 to 15 B&B scale [40] compares scores tabulated from patient self-assessment of pelvic pain, dysmenorrhea and dyspareunia together with professional assessment of pelvic tenderness and hardening (induration). Of these four, VASs and NRSs are recommended over VRSs and B&B scales for their balance of ease of administration, patient satisfaction, detection of response to treatment and low bias.

Optimal pain scale in endometriosis • Takes account of endometriosis pain specificities (such as menstrual pattern, dyspareunia) • Is adequately described, uniformly administered, validated and reliable • Is easy to administer and score / not time consuming • Can be self-administered • Has the concept of responder feasible/ Minimal Clinically Important Difference (MCID) included • Is appropriate to low literacy patients • Has worldwide translation • Access comorbidities should be captured • Has a ‘not applicable’ box (for symptoms such as dyspareunia) • Captures analgesia and complementary treatments • Has the possibility of daily pain assessment

Figure 2: Bourdel et al.’s criteria for an optimal pain scale in endometriosis. Adapted from [39].

The 2008 international Art and Science of Endometriosis meeting convened by the National Institutes of Health and American Society for Reproductive medicine recommended daily ratings of pelvic pain and dysmenorrhea using an 11-point NRS and daily recording of bleeding using a ‘none, spotting, light, heavy’ scale for primary outcome measurements in clinical research [41]. Gerlinger et al. recommend daily electronic assessment using either VAS or NRS together with a bleeding diary and a disease-specific quality of life instrument [42]. Bourdel et al. propose criteria (see Figure 2) for an optimal pain scale in endometriosis that specify daily pain assessment and accounting for “endometriosis pain specificities” such as menstrual pattern and dyspareunia [39]. Fabbri et al. argue that multidimensional approaches are required to analyse clinical histories of endometriosis patients and conclude that the MPQ appears valuable as a follow-up parameter to assessing postoperative improvement in pain [43]. Bullo identifies a need among endometriosis sufferers for assessment tools 9 that allow for better descriptions of pain beyond pain scales alone, such as indication of pain location and type [24]. Droz & Howard find that the SF-MPQ has a potential usefulness in ruling out diagnoses on chronic pelvic pain assessment [44], possible aiding more timely diagnoses of endometriosis. Ballard et al. identify common adjectives and phrases used among one cohort of endometriosis suffers and find that throbbing pain and dyschezia are likely symptoms endometriosis [45].

2.2 Related research-informed software

This section describes existing research into software that measures pain via a visual drawing feature or concerned with endometriosis in particular. Section 2.3.1 details existing research on CPBMs and section 2.3.1 details existing mHealth apps targeted for an endometriosis context.

2.2.1 Computerised pain body maps CPBMs are interactive, digital implementations of earlier paper-and-pen-based PBMs used as a diagnostic aid to pain management. CPBMs use a digital interface to indicate or draw areas of pain on a 2D or 3D model of a human body. Jaatun & Jaatun present a 2016 review of existing research driven CPBMs in the literature [46]. Of these, two aim to measure pain outside a particular demographic or diagnostic context, two are intended for patients with cancer-related diagnoses, one is aimed at both the aforementioned contexts, and one is aimed at wheelchair patients with lower back pain. One of the reviewed applications for breast cancer survivors digitizes drawings on PBMs but does not involve drawing using a digital interface and is therefore excluded from this analysis. The majority of applications are non-mobile and 2D, one is non-mobile and 3D, one is mobile and 3D, and one is designed for use on a tablet and is 2D.

Each application approaches implementation with a unique design method. Wilkie et al. [47] provide a non-mobile digital implementation of the McGill Pain Questionnaire, a component of which involves drawing areas of pain on a 2D model using a mouse or touchscreen. Serif et al. [48], Ghinea et al. [49], Spyridonis and Ghinea [50], and Grønli et al. [51] present a series of research on a mobile implementation using a segmented navigable 3D body model. The latest design iteration is implemented on the Android platform and incorporates gesture and accelerometer input to orient the model by pinching the screen to zoom and tilting the device to rotate. Users select one of five pain types and then indicate four levels of pain intensity by tapping repeatedly on the same segment.

Jamison et al. [52] present a non-mobile implementation with a fixed 3D model that is rotatable on mouse input. Users click to mark a single red point of worst experienced pain on the surface of the model and then indicate intensity by clicking on buttons to increment or decrement a 0-10 scale that is displayed to the right of the model. A cross-sectional view at the indicated point is then displayed on which users click again to mark point depth. Following indication of the point of worst pain, users are returned to the exterior view of the model on which they can click and drag to draw patterns of red points on the model. Dragging over existing points deepens their hue to indicate a greater pain intensity. 10

Lalloo and Henry [53] detail a non-mobile web-based implementation of 2D model with front (anterior/ventral) and back (posterior/dorsal) views on which users place icons that indicate different types of pain. These five types (burning, freezing, squeezing, lacerating or aching) were selected based on central poststroke pain literature which was the particular research context. From a panel displayed to the right users drag-and-drop icons representing each pain type on to perceived points of pain on the model. Buttons displayed near the model’s hands and feet allow zooming for more precise placement on these areas. Users can navigate between four chronological views (Morning, Afternoon, Evening, Overnight) using tabs displayed at the top of the screen. Descriptions of the application in the original 2011 article detail a 1-10 scale for measuring intensity for each pain type, however this feature is absent when accessing the application in 2020 (available on flash-supported browsers at http://www.emiliemcmahon.ca/pain-tool.html).

Jang et al. [54] present a non-mobile implementation with four fixed views (anterior, posterior, left-facing, right-facing) of an anatomically accurate model on which users can draw pain in red colours. Users can navigate each view via panning and zooming, and drawing can be performed either freehand or using a ‘regional’ tool to draw rectangles. A dialogue box appears after drawing with options for indicating severity, anatomical location and frequency as well as an input box for recording notes. Pain severity is indicated with a 1-10 scale that is represented visually as progressively darker hues of red. Location options allow user to specify one or more anatomical organs using checkboxes (skin, bone, muscle/joint or neural). Radio buttons allow selection of one of three frequencies (brief, periodic or continual). Dialogue boxes appear in a timeline window to the right of the model where they can be dragged either left or right to indicate chronological order. Successive inputs are automatically grouped as one symptom instance, represented visually by lines connecting drawn areas, users can cancel automatic grouping by clicking on a button in the dialogue box.

Jaatun et al. [55] detail a mobile (tablet) implementation with static 2D anterior and posterior views presented on the same screen. Users first select a pain intensity from 1-10 by tapping on radio

Authors Interface View Drawing method Distinguishing features Pain scale Comments Non- Drawing feature not well Wilkie et al. mobile, 2D, abstract Stroke - - described Mouse Serif et al., Tilt to rotate Ghinea et al., Mobile, Pinch to zoom 4-step ordinal 3D ,abstract Segment selection - Spyridonis and Ghinea, Touch Tap to increment scale (VRS?) Grønli et al. Five pain types Non- Cross-sectional view for Jamison et al. mobile, 3D, abstract Point series 0-10 NRS selecting depth Mouse Scale described in article, not Non- Five pain types present in current version of Lalloo & Henry mobile, 2D, abstract Drag-and-drop points Iconographic 0-10 NRS app Mouse representation Divisions of time not precise, subjective Freehand or rectangle selection Non- Pain duration Jang et al. mobile, 2D, realistic Stroke 1-10 NRS - Anatomical location Mouse Symptom grouping Timeline Mobile, Drawing feature not well Jatuun et al. 2D, abstract Stroke - 1-10 NRS Touch described Table 1: Design characteristics of CPBM apps in Jaatun & Jaatun [46]. 11 buttons before drawing on the model. The implementation discussed here vary markedly in complexity, design and use case. Table 1 (p. 10) compares characteristics and includes research comments for aiding design.

2.2.2 mHealth for endometriosis Instances of research-driven development of mHealth apps targeted for an endometriosis context are scarce. Gkrozou & Waters [56] present a survey of endometriosis-related mHealth apps available across app stores as of 2019, however the majority of apps reviewed are not evidence based (12 evidence based apps in total). Eight apps are identified as symptom trackers, but there is no mention of any app with a pain measuring feature. Searches for apps identified as evidence based by Gkrozou & Waters as well as general searches in research databases for mHealth apps specifically for an endometriosis context during literature review yielded no research articles.

2.3 Engineering considerations

This section covers engineering knowledge pertinent to development of the cross-platform application prototype. Section 2.3.1 covers JavaScript, section 2.3.2 summarizes the design of the React library, section 2.3.3 details the React Native framework architecture, and section 2.3.4 details how gestures and animations are handled by React Native.

2.3.1 JavaScript, JSON and NodeJS JavaScript (JS) is an interpreted, multi-paradigm programming language that incorporates first- class functions, closures, prototype-based object orientation and dynamic typing [57]. The constituent files of a JS program are called modules [58].

Functions [59] are first-class in that they may be assigned to variables as well as passed to or returned from other functions as references. Functions maintain references to the scope or lexical environment they are created in, forming closures. This allows a function reference to be passed to and called within other scopes without losing reference to the scope it was declared in. Functions may take default parameters that are used if no corresponding argument is provided.

Objects are prototype-based [60] in that instead of being instanced from abstract, pre-compiled class and inheritance declarations they are parsed at runtime and inherit their initial state directly from other objects. Objects are strictly collections of key-value pairs called properties that can be of any data type, and all objects have a hidden property that references another prototype object from which initial state is copied. Successive prototype references form prototype chains that allow objects to access properties from all ancestor prototype objects. The root of any prototype chain is the default Object prototype, and all non-primitive data types such as arrays and functions are themselves objects that inherit from this prototype. A class keyword exists in JS only as syntactic sugar for declaring prototypical objects in a class-like format [61].

JS was initially adopted for the purpose of dynamically updating web browser views and running client-side web application logic. Major implementations or engines include V8 (Chrome), 12

JavaScriptCore (Safari), SpiderMonkey (Mozilla Firefox) and Chakra (Internet Explorer). The JavaScript Object Notation (JSON) data model was created to facilitate communication between client-side JS and other server-side languages using the universal string data type [62]. JSON APIs available in each language convert between strings and each language-specific equivalent of the JS object data structure [63].

In web environments JS acts as a scripting language in the sense that it is interpreted by the browser engine for automating a range of tasks that require interfacing with a variety of external APIs. NodeJS is a runtime environment that enables the execution of stand-alone JS programs by embedding the V8 engine in a server runtime environment and providing a collection of open-source libraries that assist with range of program development tasks [64]. Libraries are groups of modules called packages by the NodeJS community; these are accessed via a CLI called the Node Package Manager (NPM) [65]. NPM and the package design pattern are not restricted to the NodeJS architecture and are used across many other frameworks and SDKs for managing third-party JS modules.

JS engines are single threaded in that only one command is processed at a time on a single call stack, though all JS runtime environments allow for asynchronous code execution by implementing a queueing system monitored by an event loop [66]. Instead of blocking, calls to external APIs specify callback functions named tasks that are scheduled to execute once the external API returns. Tasks from returning external API calls are pushed to a queue to be subsequently popped by the event loop onto the call stack whenever the call stack is empty.

JS provides a Promise API [67] as an implementation of the asynchronous callback pattern that offers additional functionalities and a more human-readable syntax. A Promise is a stateful object that encapsulates the status and return value of an asynchronous call. Asynchronous calls can immediately return a Promise with a status of ‘pending’ which subsequently changes to ‘fulfilled’ once the call completes successfully or ‘rejected’ if the call fails. Promise methods that themselves return Promises are used to handle state outcomes: .then and .catch handle fulfilled and rejected states, while .finally runs regardless of state outcome. JS provides the async and await keywords for coding functions that involve Promises. The async keyword is prepended before a function declaration or expression to allow the await keyword to be used within the function body. The await keyword is prepended to calls that return Promises.

In the JS runtime environment Promises are handled by the event loop as a separate queue of microtasks which take precedence over tasks: the microtask queue is always emptied before the task queue is accessed [66]. This API and architecture allow Promises to be chained for execution in a somewhat synchronous manner. Maintainers of external APIs choose themselves whether to return callback functions or Promises depending on use case.

13

2.3.2 React Native and React design principles React Native is a development framework that allows for cross-platform execution of JS-coded applications. It offers efficiency in development of cross-platform apps by replacing multiple native codebases and development environments with a single JS codebase that is interpreted natively on each platform. Supported platforms include smart television operating systems AndroidTV and tvOS and personal computer operating systems macOS and Windows, though it is most widely adopted in mobile app development for Android and iOS.

React Native uses React, a JS library for web application and user interface (UI) development that is designed to optimise view rendering using the Document Object Model (DOM) specification. The DOM is a mutable, tree-structured interface of nodes used in various web-related processing tasks, predominantly the rendering of views by internet browsers [68]. After parsing from an Extensible Markup Language (XML) or Hypertext Markup Language (HTML) file, each node in the DOM can be accessed and manipulated by scripting languages (predominantly JS) to dynamically change its structure. XML and HTML files convey tree structure by nesting units of code called elements which correspond to DOM nodes. Elements receive parameters called attributes and are delimited using symbols called tags. Start and end tags are used for elements that enclose nested content with attributes being declared in the start tag. Self-closing tags are used for elements that do not take any children.

React’s core concepts of reconciliation, state and component-based design are inspired by the design of the DOM, XML and HTML specifications and address inefficiencies particular to the DOM rendering environment. When the DOM is used to render views, each manipulation is followed by calls to a rendering API to update the appearance of affected nodes, making DOM manipulations programmatically expensive. Additionally, the DOM API by design favours more broad manipulations to groups of nodes over targeted manipulations to single nodes and offers no method to track DOM state. This can result in sub-optimal performance in more complex web applications where nodes that do not experience any state change are updated via the DOM due to poor state management.

React addresses this problem with reconciliation, introducing a custom tree-structured data model of the view and an algorithm to differentiate (diff) between tree model instances [69]. On application state change, React builds a new tree model of the updated view and diffs it against an existing tree model of the current view to obtain only those nodes that experience a net state change. Only after reconciliation is the DOM accessed to update net state change nodes.

React organises code into nestable units called components, each component correlates to a cohesive UI element or feature and contains code for both its appearance and logic [70]. Component structure is coded using a custom markup language called JavaScript XML (JSX) which is based on the design of XML and HTML. Component elements are delimited by tags and take parameters dubbed properties or ‘props’ which are used to pass data unidirectionally from parent components to child components. Each component can be assigned a set of variables that constitute its state, and the mutation of any stateful variable triggers reconciliation. 14

Components are coded as functions or by using the JS class keyword to extend from the React.Component object prototype. Function components implement state and state-related procedures using a ‘hooks’ API [71]. Hooks of note to this degree project are dubbed useState, useEffect, useReducer and useRef. The useState call takes an initializing value, assigns it to a stateful variable and returns it along with an associated setter function. Variable and setter can then be unidirectionally passed as props between components to be used in events that either observe or cause state change.

The useEffect call is used to define events that trigger immediately after a component is rerendered. The first parameter of useEffect is a callback function that defines the event. The second optional parameter is an array that can limit the event to triggering only if certain stateful variables have changed. If no array is provided, the effect is triggered only once after the component’s initial render. If an empty array is provided, the effect is triggered after every render.

The useReducer hook can be used to manage the state of more complex data types. Reducer functions receive a stateful variable and an action variable and return an updated state variable based on data contained in the action variable. The useReducer call takes a reducer function and an initial state and returns a stateful variable and a dispatch function. The dispatch function is then used to update state by passing in action variables.

The useRef call takes an initial value and returns a reference variable where the contained value can be accessed via the .current property. Reference variables of this type are used in React to pass data that is independent of state, such as animation values.

2.3.3 React Native architecture React Native implements React design principles using a custom runtime environment that is designed to execute across multiple platforms in place of the web-specific DOM rendering

Figure 3: Flow of events between threads during state update in React Native architecture. 15 environment. It offers a JS API that interfaces with each platform’s native functionalities for performing many common development tasks. Custom APIs for accessing native platform functionalities not exposed by the React Native API can be created using purpose-built modules called Native Modules.

The runtime environment of a React Native app (see Figure 3, p. 14) consists of a single JavaScript thread running on a JavaScriptCore engine that communicates via JSON with multiple native threads over an asynchronous bridge [72]. The bridge acts as an unprioritized message queue and has a finite capacity. On application initialization the JavaScript thread is spawned from a native main thread along with a thread for handling UI reconciliation and additional threads for running Native Modules. The JavaScript thread uses the React library to execute application logic, handle component state changes and perform reconciliation, the results of which are communicated to the native side via the bridge as a stream of commands. These are interpreted into native UI commands by the layout thread which uses tree data structures to reconcile the appearance and layout of each node. A native interface called View Manager is implemented by classes to consume commands from the JavaScript thread and produce corresponding shadow nodes which are structured into a shadow tree. A layout engine called Yoga consumes the shadow tree to produce a tree of Yoga nodes which include both appearance and layout data. The main thread then consumes the tree to render each node on screen. View events are captured by the main thread and communicated to the JavaScript thread via the bridge.

2.3.4 React Native animation and gesture handling The React Native architecture encounters performance challenges when performing gesture and animation tasks. Animation in React Native involves the manipulation of UI elements that can be independent of the reconciliation process and occur over a series of intervals called frames. Displaying at least 60 frames per second (fps) or 1 frame per 16.67 milliseconds (ms) is the gold standard for ensuring that animations appear smooth to the human eye [73]. Mobile platform hardware synchronizes application rendering cycles with predefined display refresh rates to prevent a phenomenon called screen tear where data from multiple frames are displayed in the same render. When an application fails to render a frame within the 16.67 μs time limit for a 60 fps refresh rate, platform hardware delays displaying the frame until a later refresh cycle and continues to display the preceding frame, a phenomenon called frame drop [74]. Frame drop results in animations appearing to lag or skip, or in animation jargon ‘jank’ [75], which contributes to a poor user experience.

Animations created with the default Animation API in React Native are coded declaratively and interpreted into a series of frame-by-frame operations by the JS thread, with each frame render requiring one pass through the React Native architecture. At the commencement of each new frame interval, the native main thread requests animation commands from the JS thread. The JS thread then executes the particular frame’s animation operations which are interpreted into a series of native commands via the bridge for the native thread to execute.

Animation tasks impose an extra workload on threads in addition to default React Native processes such as reconciliation. Performance is impacted by the number and complexity of 16

Figure 4: An example of frame drop in React Native, where hatch marks represent 16.67μs intervals, black boxes represent animation processes and the white box represents a non-animation processes. animations, the processing power of the device CPU and the fixed capacity of the bridge’s message queue. Slow JS thread execution and/or bottlenecks on the bridge can result in the 16.67ms time limit being exceeded and frames being dropped (see Figure 4, p. 16).

One solution to the animation performance limitation involves the JS thread serializing all operations and transmitting them as a single batch of interpreted commands to the native side when animations are triggered, allowing the native main thread to subsequently execute animation commands independently of the JS thread. This ‘native animation’ solution is however limited to only a subset of animation calls in the default Animation API as a consequence of its design [76]. A more complete solution is offered by the third party React Native Reanimated package which allows serialization of any animation operation using a more complex and imperative API [77]. Animations are coded in JS using sequences of generic calls that interface more directly with native UI methods and are serialized as described above.

Gestures are predefined sequences of touches to a device screen that trigger application events. In React Native, interaction with the device screen is captured as a stream of touch events by the main thread, and sequences of touch events are interpreted into gestures by either the main thread directly or the JS thread via the bridge depending on gesture type. React Native provides a set of components for processing certain gestures that have cross-platform native support, where the native main thread can recognize the gesture directly before signalling the gesture event to the JS thread. Other gesture events are individually coded using the Gesture Responder System and PanResponder APIs for recognition by the JS thread [78][79]. The native main thread communicates the stream of touch events to the JS thread via the bridge which in turn consults gesture related code to recognize custom coded gesture events.

The default React Native architecture and gesture handling APIs encounter inconsistencies when UIs are guided by a combination of native and custom gesture events [74][80]. The native main thread and JS thread both monitor the single stream of touch events in parallel without any protocol for prioritizing or resolving gesture events that are triggered by identical touch sequences on the separate threads. This can result in unpredictable UI behaviour when layering native and custom gesture events that can share identical subsequences, for example embedding a slider controlled by a drag gesture in a side menu that is controlled by a swipe gesture.

Non-native animations suffer from poor performance when guided by gesture events as two traversals of the bridge are required to render every new animation frame: the first traversal from native to JS results in the interpreted gesture event, and the second from JS to native transmits the corresponding animation commands for the animation frame. 17

Gesture performance limitations can be addressed using the same method as with animations: by serializing and transmitting gesture handler logic to the native main thread for execution independent of the JS thread. Combining native gestures with native animations allows execution of all related logic to be handled exclusively by the native main thread without the need for bridge traversal or processing by the JS thread while also avoiding the parallel monitoring problem. The third party React Native Gesture Handler package implements this approach by offering a set of gesture event components that execute on the main native thread [81]. It is designed to work together with the React Native Reanimated package to implement gesture-guided animations that can execute entirely in the native realm. Each component implements a unique gesture and is wrapped around the UI component that is to be guided by it. Gesture handler components can be layered and have props for fine tuning how gestures are interpreted, allowing for predictable behaviour where multiple gestures guide the same view. Gesture logic is pre-programmed, with the ‘plug-and-play’ nature of the components saving development time.

2.4 Summary of findings

Some design decisions can be informed from existing research into CPBMs as well as pain measurement both generally and in the context of endometriosis. The NRS-11 appears to be the best suited pain scale and could be complemented with multidimensional elements such as adjectives from the MPQs PRI. Pain characteristics such as type, depth, period and grouping implemented by other CPBMs could also be incorporated. An indication of abnormal bleeding recorded in tandem with pain symptoms is recommended by several sources to be essential for the dysmenorrhea context of endometriosis. Recording of other activities related to endometriosis related specificities such as dyspareunia, dyschezia and dysuria. Bourdel et al.’s criteria (see Figure 2, p. 8) can also be used to inform design decisions.

Given the architectural considerations of React Native, it is essential to prioritise the use of native gestures and animations to achieve a smooth user experience. The packages React Native Reanimated and React Native Gesture handler will be used in development to achieve this.

19

3 Methodology and Methods

This chapter presents chosen methodologies and methods that guide thesis research and project development. Section 3.1 is concerned with research methodology, section 3.2 is concerned with project methodology and section 3.3 specifies the development environment.

3.1 Research methodology and methods

This section is concerned with research methodology and methods. Research methodology literature is vast and sometimes contradictory with many overlapping terms and concepts, those presented here are based on well-cited interpretations identified during the thesis literature review. Section 3.1.1. introduces case study methodology, section 3.1.2 introduces Action research methodology, section 3.1.3 summarizes characteristics of research methodologies and sections 3.1.4 and 3.1.5 present the details of the adapted research methodology and data collection method for this thesis.

3.1.1 Case study methodology Case study is a research methodology that aims to investigate contemporary phenomena in their natural contexts [82]. Research proceeds by defining a research question together with an instance of a particular phenomenon as a case comprising of one or more units of analysis. Data on each unit of analysis is then collected in accordance with predefined protocols, after which it is validated and analysed in light of the research question in order to report findings or outcomes. Yin [83] organises this process into five distinct steps as detailed in Figure 5. Yin also distinguishes between holistic case studies with a single unit of analysis and embedded case studies with multiple units of analysis (see Figure 6), where classification of a particular phenomenon as either a case or a unit of analysis is influenced by the scope and direction of the research question.

1. Case study design: objectives are defined and the case study is planned. 2. Preparation for data collection: procedures and protocols for data collection are defined. 3. Collecting evidence: execution with data collection on the studied case 4. Analysis of collected data Figure 6: Holistic (left) and embedded (right) case studies. 5. Reporting Adapted from [52].

Figure 5: Case study research process. Adapted from [52]. 3.1.2 Action research methodology Action research is a methodology characterized by direct intervention and reflection in addition to traditional hypothesis forming and observation as means for researching a proposed problem or question [84][85]. A formal definition by Reason and Bradbury states “[Action research] seeks to bring together action and reflection, theory and practice, in participation with others, in the pursuit of practical solutions to issues of pressing concern to people” [86]. It is a cyclical, iterative process 20 focused on incrementally improving a situation or solving a problem while simultaneously building upon academic knowledge.

Figure 7: Action research methodology with inputs and outputs. Adapted from [57].

The five steps of each Action research cycle are Diagnosing, Action planning, Action taking, Evaluation and Learning [87]. Figure 17 presents these steps along with inputs and outputs of the Action research process. Diagnosing replaces the detailed problem formulation traditionally performed at commencement of a research project by instead defining an immediately actionable issue from the prevailing context at the beginning of each cycle. Action planning defines protocols for collecting and validating data and decides which interventions shall be performed on the chosen issue during Action taking. Evaluation analyses data for potential outcomes that are then documented during Learning. Each cycle has the potential to produce new knowledge and insights that contribute to the next, and Action research is focused on accommodating changes to context that can occur from cycle to cycle. Staron [87] suggests each cycle of a software Action research project lasting 1 month, for a total project time of 3-6 months.

3.1.3 Characteristics of research methodologies This section defines characteristics associated with various research methodologies, with particular focus on the context of software engineering research. These are not exhaustive or authoritative definitions as differences and overlaps in classification arise between different authors and branches of science. Section 3.1.3.1 outlines classifications of research purpose, section 3.1.3.2 presents a system of classifying research perspectives, section 3.1.3.3 defines data collection classifications and section 3.1.3.4 briefly defines the concept of research process.

3.1.3.1 Research purpose

Research purpose is what drives and defines a line of inquiry into a particular phenomenon. Purpose is essential to choosing a methodology that best serves the research process. Robson [88] classifies research purpose into four categories: 21

• Exploratory: finding out what is happening, seeking new insights and generating ideas and hypotheses for new research.

• Descriptive: portraying a situation or phenomenon.

• Explanatory: seeking an explanation of a situation or a problem, mostly but not necessarily in the form of a causal relationship

• Improving: trying to improve a certain aspect of the studied phenomenon.

Research purpose is reflected in the research question that is defined at the beginning of a research project. Easterbrook et al. [7] define a system of categorisation that connects purpose to question type as presented in Table 2 below.

Question category Question type Question example

Exploratory Existence “Does X exist?”

Description and Classification “What are the properties of X?”

Descriptive-Comparative “How does X differ from Y?”

Base rate Frequency and distribution “How often does X occur?”

Descriptive-Process “How does X achieve its purpose?”

Relationship Relationship “Are X and Y related?”

Causality Causality “Does X cause Y?”

Causality-Comparative “Does X cause more Y than does Z?”

Causality-Comparative Interaction “Does X or Z cause more Y under one condition but not others?” Table 2: A categorisation of research questions. Adapted from Easterbrook et al. [7].

3.1.3.2 Research perspective

The validity of data and analysis depends on the research perspective which determines what is accepted as empirical truth. In questions of truth, philosophy distinguishes between the concepts of epistemology and ontology, or the nature of human knowledge and its acquisition versus the true nature of existence irrespective of how human understand it. Easterbrook et al. [7] defines four dominant philosophical stances on empirical truth:

• Positivism states that knowledge is incrementally built from inferences based on verified observations of a phenomenon’s component parts. Positivist methodology is based on precise theories from which hypotheses can be extracted and tested in isolation.

• Constructivism or Interpretivism asserts that human context cannot be separated from knowledge, and that interpretation of theory is as important as the truthfulness of the observations on which it is based. Methodology is focused on understanding how individuals and/or groups make sense of a phenomenon. 22

• Critical theory focuses on the role of scientific knowledge in freeing people from restrictive systems of thought. Research is conducted in order to empower a chosen community within society.

• Pragmatism acknowledges that all knowledge is incomplete, and its value depends on the methods by which it was obtained [89]. Truth is relative and based on consensus and rational argument, and knowledge is judged based on how it contributes to solving practical problems.

Research perspective is also formed from the method of reasoning used:

• Deductive reasoning aims to test an existing theory by proceeding from general principles to specific instances.

• Inductive reasoning aims to develop theories by proceeding from specific observations to general conclusions.

Research can be conducted from multiple perspectives in order to reduce bias. Triangulation is the practice of taking multiple perspectives on research objects [90]:

• Data (source) triangulation: using multiple sources of data and/or multiple instances of data collection

• Observer triangulation: enlisting multiple observers during research

• Methodological triangulation: using multiple methods for data collection (e.g. both quantitative and qualitative)

• Theory triangulation: examining multiple theories or viewpoints

3.1.3.3 Data collection

Research data is classified according to the following types:

• Quantitative data is measurable and is expressed numerically or ordinally. Quantitative methods examine data relationships and patterns using statistics and formulae to compare and contrast.

• Qualitative data is approximate and characterizing and is expressed in language or symbology. Qualitative methods seek to identify patterns in data and/or to code meaning to data according to a stated theory or hypothesis.

Classifications also exist for sources of data. Lethbridge defines a classification system particular to software engineering field research [91]:

• First degree: data collection from direct involvement with subjects such as interviews, focus groups or questionnaires

• Second degree: data collection from indirect involvement with subjects such as keylogging or software monitoring 23

• Third degree: data collection via analysis of existing artefacts or compiled data such as documented systems, logs or databases

3.1.3.4 Research flexibility

Anastas & MacDonald [92] and Robson [88] classify research process as fixed or flexible, where in a fixed research process all parameters are defined at the beginning of research while a flexible process allows for parameters to be changed as research progresses.

3.1.4 Adapted research methodology The adapted research methodology for this instance of research is inspired by Case study and Action research methodologies and is defined according to criteria outlined in section 3.1.3. It is a flexible process-descriptive case study incorporating elements of action research, supported by third-degree qualitative data. The unit of analysis is the feature developed during the engineering project. It takes a pragmatist, deductive research perspective in that it focuses on solving a specific practical problem by applying more generalised knowledge and theory obtained during a literature review.

Figure 8: The adapted research methodology with inputs and outputs.

Figure 8 outlines the steps of the adapted research methodology, where rectangles are steps and circles are inputs and outputs of the research process. Case study design and data collection protocols are defined during the Case selection step. Evidence collection is inspired by the iterative, cyclical design of Action research, but on a much smaller scale: each cycle represents the identification and solving of a design/development subproblem belonging to an engineering project, with a cycle duration of days as opposed to months. Each planning step involves drawing upon existing knowledge obtained during the literature review and identifying any new required knowledge in light of the specific subproblem to be solved, as well as outlining a development strategy to be followed during 24 execution. The execution step involves actual development tasks undertaken to solve the subproblem. The evaluation step involves testing and validating each solution. The collation of solutions to all subproblems is given in the presentation of results, which is analysed in the discussion step.

3.1.5 Research method In following the adapted research methodology, this thesis extracts two subquestions from the research question and addresses them in different steps of the methodology. The overarching research question is then addressed by addressing each subquestion separately. The research subquestions are detailed in Table 3.

Research question How can a cross-platform, visual, gesture-guided and research-informed mHealth application for measuring pelvic pain associated with endometriosis be developed?

Subquestion 1 What existing knowledge can inform development of the described application?

Subquestion 2 How can relevant application features be developed using acquired knowledge? Table 3: Research question and subquestions

Subquestion 1 is addressed in the literature review step of the adapted research methodology, which is detailed in Section 2. The literature review summarizes relevant knowledge from two categories: existing pain, endometriosis and CPBM research that can be used to inform design decisions and software engineering knowledge required to implement design decisions as a cross- platform application prototype. The findings of the literature review are used as the basis for addressing Subquestion 2.

Subquestion 2 is addressed in the evidence collection step of the adapted research methodology, the results of which are presented in Section 4. Each evidence collection cycle represents the definition, implementation and evaluation of a single research-informed software requirement. Each cycle’s planning phase involves the definition of a cohesive software requirement from the body of first category design-informing knowledge presented by the literature review. This is done with the assistance of a MoSCoW analysis as described in Section 3.2.2. The execution phase involves the application of second category software engineering knowledge to implement the software requirement as a functionality in code as well as documentation of the process. The evaluation phase involves manual testing of the functionality for reliability as described in Section 3.3.3.

3.1.6 Research evaluation Shaw [93] identifies 6 types of evaluation used in software engineering research, of which the ‘example’ method is employed to evaluate the results of this thesis. Evaluation by example is used in software engineering research that presents a new development method, where a functioning “slice of life” system or program validates the design and implementation outcomes discussed in the research text. The adapted methodology employs this evaluation method in each cycle of the evidence collecting step via a thorough manual testing process as described in section 3.3.3. The completed and functioning prototype serves as an evaluating system for the collated result of the thesis, which describes a development method for a prototype for assessing endometriosis-related pelvic pain. 25

26

3.2 Project methodology and methods

As this thesis describes research conducted in sequence with a degree project, a brief description of the methodology guiding project development is included. Section 3.2.1 introduces Lean and Agile methodology and section 3.2.2 introduces the MoSCoW method that is used to prioritise feature development.

3.2.1 Agile, Lean, and adapted project methodology The terms Agile and Lean are not precisely defined in literature and encompass many contradictory and overlapping concepts due to being developed informally by practitioners [94][95]. The concept of Agile has its origin story in the adoption of the Agile Manifesto [96] by followers of a range of various software development methods in 2001 [97]. Lean software methods developed from manufacturing- focused predecessors, most notably the Toyota Production System [98], gaining popularity among software development teams in the 2000s.

The adapted project methodology used to guide development during this degree project is inspired by Poppendieck & Poppendieck’s Lean Software Development [99], particularly the four concepts Eliminate Waste, Amplify Learning, Decide as Late as Possible, Deliver as Fast as Possible. Focus on iterative development and knowledge building echoes Action research concepts, while focus on deferment of decisions, fast delivery and only necessary features works well with MoSCoW analysis discussed below.

3.2.2 MoSCoW analysis MoSCoW (Must, Should, Could, Won’t) analysis is a name given to a method developed by Clegg [100] for defining requirement in projects with fixed deadlines. It recognizes that all features are important but that a hierarchy of importance can be established in order to prioritize feature development so that projects meet deadlines. Features are classified based on what the final product must, should, could and won’t have.

A MoSCoW analysis is applied in the Planning phase of the adapted research methodology to identify additional software requirements desired by Endometrix as well as to delimit the scope of the project. When a research-informed software requirement is identified, is it classified as either ‘must’ or ‘won’t’ depending on how it complements existing functionalities in the Endometrix app as well as the estimated development time. Requirements deemed achievable within the project deadline and that aren’t already fulfilled by existing or planned functionalities in the Endometrix app are classified as ‘must’. Requirements that do not meet these criteria are classified as ‘won’t’. Additional features that complement ‘must’ requirements and that are achievable within the project deadline are then defined as ‘should’ and ‘could’ prioritizations. 27

3.3 Development environment

This section details the various development tools used to deliver the degree project. Section 3.3.1 presents the Expo development framework, section 3.3.2 outlines the environment setup, and section 3.3.3 outlines how testing was handled during development.

3.3.1 Expo Expo is a development framework that extends React Native with an additional library of cross- platform Native Modules for Android, iOS and web and is preconfigured to minimize project setup and maintenance. Expo provides a local development server with a quick refresh feature and a content delivery network (CDN) to which apps may be deployed. Deployed apps can be accessed via unique links using the Expo client app for Android or iOS.

The Expo development environment consists of a browser UI, the expo development server, the react native package server and the client app. The client app first connects to the Expo development server which serves a configuration manifest including a link to the bundled app URL. The link accesses a bundled JS file containing the entire React Native project which is downloaded onto the Expo client app for execution.

Deployed apps are accessed in a similar runtime environment where the manifest is served by Expo’s backend servers, and the JS bundle is served by the Amazon Cloudfront CDN. The client app caches JS bundles and accesses the most current bundle version in the case of offline access.

3.3.2 Environment setup Development was conducted using Visual Studio Code running Expo and Git in inbuilt terminal windows, together with Simulator and Android Studio which provide iOS and Android phone emulators. Emulators can be launched and connected to the development server directly from the Expo browser interface and update to instantly reflect any changes saved in Visual Studio Code.

3.3.3 Manual testing Testing was conducted manually on both emulated and physical iOS and Android smartphones. A physical iPhone 8, iPhone 8 Plus and an emulated iPhone 12 Pro Max were used to test on iOS while a physical Doro 8040 and an emulated Pixel 2 and Pixel 3 were used to test on Android. Each meaningful code update was tested rigorously across all mentioned smartphone softwares by manually and exhaustively interacting with the prototype and observing for bugs.

. 28

4 Results

This section presents the results of the thesis which are based on the outcomes of the prototype development process and which address the second research subquestion presented in section 3.1.5 (p. 24): “How can relevant application features be developed using acquired knowledge?”. Section 4.1 presents requirements that were identified from knowledge gathered during the literature review and how requirements where prioritized via application of MoSCoW analysis to suit project goals at Endometrix. Section 4.2 presents each research-informed feature included in the completed application prototype.

4.1 Software requirement definition

Requirement Research sources

Visual, gesture-guided drawing of pelvic pain Endometriosis research (section 2.1.1), CPBM research (section 2.2.1)

Daily tracking Bourdel et al. [39], Vincent et al. [41], Gerlinger et al. [42]

Pain typing Bullo [24], Ballard et al. [45], Fabbri et al. [43]

NRS for pain intensity Bourdel et al. [39], Vincent et al. [41], Gerlinger et al. [42]

Pain frequency Rush et al [25]., Jang et al. [54]

Tracking of endometriosis pain specificities Bourdel et al. [39], Morotti et al. [19], Amer [18] (dysmenorrhea, dyspareunia, dyschezia, dysuria)

Bleeding diary (none, spotting, light, heavy) Bourdel et al. [39], Vincent et al. [41]

Measure MCID Bourdel et al. [39]

Capture analgesia and complementary treatments Bourdel et al. [39]

Quality-of-life assessment Bourdel et al. [39] Table 4: Potential software requirements identified from the literature review.

Table 4 presents a summary of potential research-informed software requirements and corresponding literature review sources that were identified during each planning phase within the evidence collection step of the research method described in section 3.1.5. Not all potential requirements were selected for implementation in the application prototype due to project scope and prioritization at Endometrix. Figure 9 (p. 28) presents the prioritization of software requirements after application of MoSCoW analysis as described in section 3.2.2. Seven of the ten identified requirements were prioritized as ‘must’ due to research evidence present across a range of sources as well as their estimated complexity fitting within project scope. Three requirements were prioritized as ‘won’t’: “measuring MCID” and “capturing potential analgesia” requirements were deemed out of project scope due to the estimated complexity of their implementation, whereas quality-of-life assessment is addressed by other features already included in the Endometrix smartphone app. The ‘should’ and ‘could’ prioritizations reflect requirements that are not necessarily research based yet complement ‘must’ prioritizations and fit the development goals for the Endometrix prototype. 29

Prioritization Requirement

Must • Gesture-guided drawing of pelvic pain • Daily tracking • Pain typing

• NRS for pain intensity • Pain frequency • Tracking of endometriosis pain specificities (dysmenorrhea, dyspareunia, dyschezia, dysuria) • Bleeding diary (none, spotting, light, heavy)

Should • Adjusting stroke size with pinch gesture • Accounting of stroke depth • Visual appearance of stroke changes to reflect tooltip selections • Persistence of entered tracking data • Tutorial page

Could • External database storage • Interactive tutorial

Won’t • Measure MCID • Capture analgesia and complementary treatments

• Quality-of-life assessment Figure 9: Prioritization of requirements with MoSCoW analysis.

30

4.2 Research-informed application features

This section presents features of the application prototype that have been developed based on clinical research and using engineering knowledge presented in the literature review. Section 4.2.1 presents a summary of prototype features to give context to individual feature descriptions. Sections 4.2.2 – 4.2.8 present the implementation of each research-informed software requirement as features and cites research specific to the design of each feature. These sections are preceded by excerpts from the MoSCoW prioritization presented in Figure 9 (p. 28) which specify which requirements have been addressed.

4.2.1 Prototype overview The completed app prototype offers a CPBM for daily tracking of pelvic pain, a tooltip for daily tracking of endometriosis pain specificities (dubbed ‘factors’) and a calendar for accessing previous tracking entries (see Figure 10). The app opens on the CPBM screen where the user can begin to draw pain ‘strokes’, access the factors tooltip, access the calendar or access a tutorial modal that explains how to use the app. Users may enter new pain strokes, inspect and delete existing strokes, and alter factors over the course of each 24-hour day, with all alterations being saved instantly to phone memory. The CPBM refreshes to a new blank instance at midnight of each new day, and previous days can be accessed and retroactively edited via the calendar.

Figure 10: Factors screen (left), draw screen with front (middle left) and back (middle right) views, and calendar screen (right)

The CPBM is abstract with front and back views that each have three levels of depth accompanied by a dynamic tooltip displayed beneath it. Users swipe the screen with one finger to change between front and back views and tap with two fingers to cycle between depths, which are indicated visually by the changing opacity of the model as well as in a legend displayed directly under the model. Once the appropriate view and depth is selected, the user can begin drawing an instance of pain by pressing the draw button. Figure 11 (p. 31) shows each step involved in adding a pain stroke. The user first pinches to adjust stroke width before drawing on the model to indicate a specific instance of pain. The pain type, intensity and period can then be indicated in the tooltip, with each selection updating the 31

appearance of the drawn stroke. Each pain type has a unique colour, and the colour tint changes to reflect the selected pain intensity. Pain intensity is selected from a 1-10 NRS. Pain period is indicated as brief, periodical or continuous. The user can then enter a note associated with the pain stroke to indicate any information not captured in the previous steps. A tooltip summarizing stroke information is then displayed in which users can select to either save or delete the stroke. Strokes remain visible only at the view and depth they are drawn in. Strokes can be selected by pressing on them, which displays the stroke information tooltip with the options to save and close or to delete the stroke.

Figure 11: (From left to right) Selecting pain type, intensity, and frequency, entering a note and the stroke info tooltip.

Accessing the factors tooltip (see Figure 10, left) displays six buttons for tracking indicating dyspareunia, dyschezia, dysuria as well as bleeding for the current date. Dyspareunia, dyschezia and dysuria are indicated by selecting or deselecting a related icon button from the top row of buttons, while bleeding intensity and pain indicated by selecting either none or one of three bottom row buttons. Pressing one of the bleeding intensity buttons once displays a red border, indicating incidence of the intensity without pain. A second press fills the entire button with a red colour to indicate incidence of the intensity with pain, and a third press deselects the intensity.

4.2.2 CPBM design

Prioritization Requirement

Must • Gesture-guided drawing of pelvic pain

Should • Adjusting stroke size with pinch gesture • Accounting of stroke depth • Visual appearance of stroke changes to reflect tooltip selections

Limiting the scope of the model to that of a female pelvis was a Lean decision in light of literature review knowledge presented in section 2.1.1 that indicates the majority of those that experience endometriosis have female sex organs, and that while pain can occur anywhere in the body it is most prevalent in the pelvis. High incidence of pelvic pain is best demonstrated in diagrams of anatomical site specific pain presented by Schliep et al. [20]. The static 2D model with ventral and dorsal views 32 has precedence in CPBM literature and was chosen as the Lean option over the inherently more complex development task of producing a 3D model. The inclusion of depth levels is based on a similar albeit 3D-based feature of the CPBM described by Jamison et al. [52].

The navigation between ventral and dorsal views and depths within views along with the drawing of strokes on the model is implemented via the application of knowledge on React Native state as described in section 2.3.2 and knowledge on gesture handling and animation as described in section 2.3.4. Swiping and tapping on the model trigger gesture handlers that update state variables created by useState hooks to trigger reconciliation, in turn updating the view. Panning on the model to draw strokes triggers a stream of state updates that cause the stroke path to follow finger movement in real time. This logic is handled on the JS thread due to a limitation in the Polyline component that does not allow for native animation. However, non-native animation of strokes in this implementation does not lead to frame drop as only one component is being continuously updated at a time and no other process-intensive tasks are executing in the JS realm simultaneous to the drawing process.

4.2.3 Daily tracking and calendar

Prioritization Requirement

Must • Daily tracking

Should • Persistence of entered tracking data

A 24-hour period for tracking pain was informed by authoritative recommendations documented in Bourdel et al. [39], Vincent et al. [41] and Gerlinger et al. [42] that specify use of a daily tracking period for endometriosis related pain. The calendar was included to clearly differentiate between tracking periods and to allow for navigation between them (see Figure 10, right, p. 30).

4.2.4 Pain types

Prioritization Requirement

Must • Pain types

Should • Visual appearance of stroke changes to reflect tooltip selections

The user is required to specify a pain type directly after drawing a pain stroke from one of 7 colour- coded pain types, and upon selection the colour of the stroke is updated to reflect the corresponding colour (see Figure 12, p. 32). Pain types have precedence in Lalloo & Henry’s CPBM [53] and attempt to capture metaphorical descriptions of endometriosis pain as described by Bullo [24]. The pain adjectives were chosen by cross referencing adjectives from the PRI section of the MPQ with a set of adjectives that are commonly mentioned by endometriosis sufferers as described by Ballard et al. [45]. The use of arbitrary colours to differentiate between pain types is informed by Jang et al. [54] who note in a pilot study of their CPBM that colour plays no intrinsic role in classifying types of pain. The implementation of this feature draws on knowledge of the React Native’s reconciliation process and hooks as described in section 2.3.2 (p. 13). 33

Figure 13: Selecting the ‘Throbbing’ pain type changes the colour of the drawn stroke.

Figure 12: Selecting a pain intensity updates the colour of the stroke to the corresponding shade. 34

4.2.5 Pain intensity scale

Prioritization Requirement

Must • NRS for pain intensity

Should • Visual appearance of stroke changes to reflect tooltip selections

The user specifies a pain intensity from 1-10 NRS after selecting the pain type, where each increment has a progressively darker shade of pain type colour (see Figure 13, p. 32). Upon selecting an intensity, the colour of the stroke is updated to the corresponding shade. The NRS was chosen to measure pain based on its wide adoption and recommendation in general pain measurement research (see section 2.1.2) as well as in the specific case of endometriosis-related pain assessment, being recommended as a preferred pain scale in both Vincent et al. [41] and Gerlinger et al. [42]. The use of shades of colour to indicate intensities was inspired by Jang et al.’s [54] use of colour for the same purpose. The implementation of this feature draws on knowledge of the React Native’s reconciliation process and hooks as described in section 2.3.2 (p. 13).

4.2.6 Pain frequency

Prioritization Requirement

Must • Pain frequency

Should • Visual appearance of stroke changes to reflect tooltip selections

The user specifies a pain frequency from one of three buttons after selecting intensity, after which the pain stroke is overlayed with either a dashed or unbroken white line to indicate periodical or continuous pain frequency, or no line to indicate a brief incidence of pain (see Figure 14). The requirement for capturing frequency is informed by Rush et al.’s [25] findings on correlation between

Figure 14: Indicating 'periodical' frequency updates stroke appearance. 35 higher symptom frequency and lower levels of subjective wellbeing in endometriosis suffers. The three categories of frequency are inspired by their implementation in Jang et al.’s CPBM [54]. The implementation of this feature draws on knowledge of the React Native’s reconciliation process and hooks as described in section 2.3.2 (p. 13).

4.2.7 Factors

Prioritization Requirement

Must • Tracking of endometriosis pain specificities (dysmenorrhea, dyspareunia, dyschezia, dysuria)

In the ‘Factors’ view the user can select or deselect three icon buttons to indicate if painful sex, painful urination or painful defecation has occurred during the corresponding tracking period (see Figure 15). This feature addresses research indicating dyspareunia, dyschezia, and dysuria symptoms being associated with endometriosis [18][19][20] and recommendations in Bourdel et al. [39] for tracking of these symptoms. The implementation of this feature draws on knowledge of the React Native’s reconciliation process and hooks as described in section 2.3.2 (p. 13).

Figure 15: Factor buttons (top row) with dysuria selected. 4.2.8 Bleeding scale

Prioritization Requirement

Must • Tracking of endometriosis pain specificities (dysmenorrhea, dyspareunia, dyschezia, dysuria) • Bleeding diary (none, spotting, light, heavy) with pain indication

In the ‘Factors’ view the user can indicate four levels of menstrual bleeding along with incidence of associated pain by pressing either once or twice on a corresponding scale button (see Figure 16, p. 35). The design of this scale is intended fulfil the recommendation outlined by Bourdel et al. [39] for a 36 daily bleeding diary and tracking of dysmenorrhea and Vincent et al. [41] for indication of daily bleeding using a ‘none, spotting, light, heavy’. In addition, it fulfils the recommendations from these sources for tracking dysmenorrhea. The implementation of this feature draws on knowledge of the React Native’s reconciliation process and hooks as described in section 2.3.2 (p. 13).

Figure 16: Selecting a degree of bleeding without pain (left) and with pain (right).

37

5 Discussion and Conclusion

This selection presents the conclusions of the thesis. Section 5.1 presents an analysis of the reliability of methods and results, section 5.2 presents an analysis of the reliability and validity of data, section 5.3 presents a summary of research outcomes, and section 5.4 discusses limitations and future work.

5.1 Reliability and validity of methods and results

The methods and results of this thesis cannot be asserted to have high reliability due to the specific nature of the research environment, that is, the state of research used to support design decisions at the time that research into this thesis was conducted, and the specific requirements desired for the particular implementation at Endometrix. The outcomes of reproducing the results of this thesis would vary widely based on developments within pain assessment, endometriosis and CPBM research over time and the individual requirements of the stakeholders involved in design decisions.

The validity of the methods and the produced results can be asserted by the underlying adapted methodology which is in turn based on well-established methodologies and methods (Case study, Action research and MoSCoW analysis). These three concepts have a history of application within software engineering research to produce robust results that have been accepted by the research community.

5.2 Reliability and validity of data

This thesis collates qualitative data from a literature review and produces its own qualitative data in the form of source code and design documentation. Sections 2.1 and 2.2 of the literature draw on data from peer reviewed academic articles, where the peer review process as well as how widely each article is referenced affirms data reliability and validity. Section 2.3 references the Mozilla Development Network (MDN) website for JavaScript information and React documentation together with filmed coding presentations for information on React Native. These sources are not peer reviewed, yet their reliability and validity can be affirmed in that the MDN and React sites are recognized as authoritative sources of information for JavaScript and the React framework respectively. Information on React Native’s architecture is not disclosed in official documentation and is instead supported by references to recorded presentations from community conferences. The reliability and validity of this information can be affirmed from the official React website sanctioning of referenced conferences as official community resources [101]. Source code data reliability and validity is affirmed by thorough manual testing of the developed functionality throughout the project.

5.3 Research outcomes

This thesis investigates a descriptive-process research question using a hybrid case study / action research methodology where knowledge obtained from a literature review is applied to an iterative software development process. In doing so the main research question “How can a cross-platform, visual, gesture-guided and research-informed mHealth application for measuring pelvic pain 38 associated with endometriosis be developed?” is addressed by answering each of the two research subquestions separately:

SQ1: What existing knowledge can inform development of the described application?

This thesis asserts the answer to be thorough background knowledge on pain scale assessment, endometriosis, pain assessment in endometriosis and CPBMs is required, particularly recommendations from official bodies representing endometriosis research. Knowledge in a particular cross-platform development environment is also required for engineering considerations, in this case knowledge in React Native.

SQ2: How can relevant application features be developed using acquired knowledge?

This thesis asserts development shall proceed by iteratively identifying cohesive software requirements from collected knowledge, delimiting these requirements with reference to the particular research environment, and then designing interfaces and logic in code based on the delimited requirements which shall then be evaluated through thorough manual testing. Section 4 presents the results specific to the research environment of this thesis. This thesis asserts that relevant features for a visual, gesture-guided and research-informed mHealth application for measuring pelvic pain associated with endometriosis include:

• A CPBM of the pelvis with ventral/dorsal views and three depth layers to each view

• A daily tracking period with calendar interface

• Colour-coded pain typing using endometriosis-relevant adjectives

• Colour-coded pain scaling using 1-10 NRS

• Pain frequency indication

• Toggle interface for indicating dyspareunia, dysuria, and dyschezia

• Scale/toggle interface (‘bleeding scale’) for indicating daily bleeding along with dysmenorrhea

5.4 Limitations and future work

This thesis is limited to describing one software solution to the research question. The results do not affirm the effectiveness of the solution nor compare it against other possible solutions. A logical next step would be to investigate the effectiveness of the solution. User surveys could gather data about what works and what could work better with the prototype. The prototype could be surveyed in a clinical setting to see if patients receive any benefit from using the functionality. More research could also be conducted into how the design choices of a CPBM affect its effectiveness for pain assessment in a particular clinical setting, for example comparing the effectiveness of abstract versus anatomically accurate human models. The design decisions documented in this thesis could be drawn on in future work concerning software engineering for research-based mHealth pain assessment or endometriosis focused applications. 39

References

[1] Charles Musselwhite, Shannon Freeman, and Hannah R. Marston, ‘An Introduction to the Potential for Mobile eHealth Revolution to Impact on Hard to Reach, Marginalised and Excluded Groups’, in Mobile e-Health, H. R. Marston, S. Freeman, and C. Musselwhite, Eds. Cham: Springer International Publishing, 2017, pp. 3–13 [Online]. DOI: 10.1007/978- 3-319-60672-9_1 [2] WORLD HEALTH ORGANIZATION, GLOBAL DIFFUSION OF EHEALTH: making universal health coverage achievable. GENEVA: WORLD HEALTH ORGANIZATION, 2017, ISBN: 978-92-4-151178-0. [3] Kyle Taylor and Laura Silver, ‘Smartphone Ownership Is Growing Rapidly Around the World, but Not Always Equally’, Pew Research Centre, Feb. 2019. [4] ‘The Growing Value of Digital Health: Evidence and Impact on Human Health and the Healthcare System’, IQVIA Institute, Nov. 2017. [5] Chitra Lalloo, Lindsay A. Jibb, Jordan Rivera, Arnav Agarwal, and Jennifer N. Stinson, ‘“There’s a Pain App for That”: Review of Patient-targeted Smartphone Applications for Pain Management’, Clin. J. Pain, vol. 31, no. 6, 2015 [Online]. Available: https://journals.lww.com/clinicalpain/Fulltext/2015/06000/_There_s_a_Pain_App_for_That___Review_of.9.aspx [6] ‘Mobile Operating System Market Share Worldwide’, StatCounter Global Stats. [Online]. Available: https://gs.statcounter.com/os-market-share/mobile/worldwide. [Accessed: 14-Dec-2020] [7] Steve Easterbrook, Janice Singer, Margaret-Anne Storey, and Daniela Damian, ‘Selecting Empirical Methods for Software Engineering Research’, in Guide to Advanced Empirical Software Engineering, F. Shull, J. Singer, and D. I. K. Sjøberg, Eds. London: Springer London, 2008, pp. 285–311 [Online]. DOI: 10.1007/978-1-84800-044-5_11 [8] Linda C Giudice and Lee C Kao, ‘Endometriosis’, The Lancet, vol. 364, no. 9447, pp. 1789–1799, Nov. 2004. DOI: 10.1016/S0140-6736(04)17403-5 [9] Michelle Nisolle and Jacques Donnez, ‘Peritoneal endometriosis, ovarian endometriosis, and adenomyotic nodules of the rectovaginal septum are three different entities’, Fertil. Steril., vol. 68, no. 4, pp. 585–596, Oct. 1997. DOI: 10.1016/S0015- 0282(97)00191-X [10] Leslie V. Farland, Divya K. Shah, Marina Kvaskoff, Krina T. Zondervan, and Stacey A. Missmer, ‘Epidemiological and Clinical Risk Factors for Endometriosis’, in Biomarkers for Endometriosis: State of the Art, T. D’Hooghe, Ed. Cham: Springer International Publishing, 2017, pp. 95–121 [Online]. DOI: 10.1007/978-3-319-59856-7_6 [11] Krina T. Zondervan, Lon R. Cardon, and Stephen H. Kennedy, ‘What makes a good case–control study?: Design issues for complex traits such as endometriosis’, Hum. Reprod., vol. 17, no. 6, pp. 1415–1423, Jun. 2002. DOI: 10.1093/humrep/17.6.1415 [12] Christina Rei, Thomas Williams, and Michael Feloney, ‘Endometriosis in a Man as a Rare Source of Abdominal Pain: A Case Report and Review of the Literature’, Case Rep. Obstet. Gynecol., vol. 2018, p. 2083121, Jan. 2018. DOI: 10.1155/2018/2083121 [13] Camran Nezhat, Farr Nezhat, and Ceana Nezhat, ‘Endometriosis: ancient disease, ancient treatments’, Fertil Steril, vol. 98, no. 6, pp. S1–S62, 2012. DOI: 10.1016/j.fertnstert.2012.08.001 [14] G. Benagiano, I. Brosens, and D. Lippi, ‘The History of Endometriosis’, Gynecol. Obstet. Invest., vol. 78, no. 1, pp. 1–9, 2014. DOI: 10.1159/000358919 [15] Peter A W Rogers, Thomas M D’Hooghe, Asgerally Fazleabas, Caroline E Gargett, Linda C Giudice, Grant W Montgomery, Luk Rombauts, Lois A Salamonsen, and Krina T Zondervan, ‘Priorities for endometriosis research: recommendations from an international consensus workshop’, Reprod. Sci. Thousand Oaks Calif, vol. 16, no. 4, pp. 335–346, Apr. 2009. DOI: 10.1177/1933719108330568 [16] Ruth Hadfield, Helen Mardon, David Barlow, and Stephen Kennedy, ‘Delay in the diagnosis of endometriosis: a survey of women from the USA and the UK’, Hum. Reprod., vol. 11, no. 4, pp. 878–880, Apr. 1996. DOI: 10.1093/oxfordjournals.humrep.a019270 [17] Kelechi E Nnoaham, Lone Hummelshoj, Premila Webster, Thomas d’Hooghe, Fiorenzo de Cicco Nardone, Carlo de Cicco Nardone, Crispin Jenkinson, Stephen H Kennedy, Krina T Zondervan, and World Endometriosis Research Foundation Global Study of Women’s Health consortium, ‘Impact of endometriosis on quality of life and work productivity: a multicenter study across ten countries’, Fertil. Steril., vol. 96, no. 2, pp. 366-373.e8, Aug. 2011. DOI: 10.1016/j.fertnstert.2011.05.090 [18] Saad Amer, ‘Endometriosis’, Obstet. Gynaecol. Reprod. Med., vol. 18, no. 5, pp. 126–133, May 2008. DOI: 10.1016/j.ogrm.2008.03.003 [19] Matteo Morotti, Katy Vincent, and Christian M. Becker, ‘Mechanisms of pain in endometriosis’, SI Endometr., vol. 209, pp. 8–13, Feb. 2017. DOI: 10.1016/j.ejogrb.2016.07.497 [20] KC Schliep, SL Mumford, CM Peterson, Z Chen, EB Johnstone, HT Sharp, JB Stanford, AO Hammoud, L Sun, and GM Buck Louis, ‘Pain typology and incident endometriosis’, Hum. Reprod., vol. 30, no. 10, pp. 2427–2438, 2015. [21] Linda C Giudice, ‘Endometriosis’, N. Engl. J. Med., vol. 362, no. 25, pp. 2389–2398, 2010. DOI: 10.1056/nejmcp1000274 [22] A. Fauconnier and C. Chapron, ‘Endometriosis and pelvic pain: epidemiological evidence of the relationship and implications’, Hum. Reprod. Update, vol. 11, no. 6, pp. 595–606, Nov. 2005. DOI: 10.1093/humupd/dmi029 40

[23] Mike Armour, Justin Sinclair, K. Jane Chalmers, and Caroline A. Smith, ‘Self-management strategies amongst Australian women with endometriosis: a national online survey’, BMC Complement. Altern. Med., vol. 19, no. 1, p. 17, Jan. 2019. DOI: 10.1186/s12906-019-2431-x [24] Stella Bullo, ‘“I feel like I’m being stabbed by a thousand tiny men”: The challenges of communicating endometriosis pain’, Health (N. Y.), vol. 24, no. 5, pp. 476–492, Feb. 2019. DOI: 10.1177/1363459318817943 [25] Georgia Rush, RoseAnne Misajon, John A. Hunter, John Gardner, and Kerry S. O’Brien, ‘The relationship between endometriosis-related pelvic pain and symptom frequency, and subjective wellbeing’, Health Qual. Life Outcomes, vol. 17, no. 1, p. 123, Jul. 2019. DOI: 10.1186/s12955-019-1185-y [26] C.R. Chapman, K.L. Casey, R. Dubner, K.M. Foley, R.H. Gracely, and A.E. Reading, ‘Pain measurement: an overview’, Pain, vol. 22, no. 1, pp. 1–31, May 1985. DOI: 10.1016/0304-3959(85)90145-9 [27] R. Cowen, M. K. Stasiowska, H. Laycock, and C. Bantel, ‘Assessing pain objectively: the use of physiological markers’, Anaesthesia, vol. 70, no. 7, pp. 828–847, Jul. 2015. DOI: 10.1111/anae.13018 [28] Debra B Gordon, ‘Acute pain assessment tools: let us move beyond simple pain ratings’, Curr Opin Anaesthesiol, vol. 28, no. 5, pp. 565–569, 2015. DOI: 10.1097/ACO.0000000000000225 [29] W Crawford Clark, Joseph C Yang, Siu-Lun Tsui, Kwok-Fu Ng, and Susanne Bennett Clark, ‘Unidimensional pain rating scales: a multidimensional affect and pain survey (MAPS) analysis of what they really measure’, Pain, vol. 98, no. 3, pp. 241–247, Aug. 2002. DOI: 10.1016/S0304-3959(01)00474-2 [30] Marianne Jensen Hjermstad, Peter M. Fayers, Dagny F. Haugen, Augusto Caraceni, Geoffrey W. Hanks, Jon H. Loge, Robin Fainsinger, Nina Aass, and Stein Kaasa, ‘Studies Comparing Numerical Rating Scales, Verbal Rating Scales, and Visual Analogue Scales for Assessment of Pain Intensity in Adults: A Systematic Literature Review’, J. Pain Symptom Manage., vol. 41, no. 6, pp. 1073–1093, Jun. 2011. DOI: 10.1016/j.jpainsymman.2010.08.016 [31] Ana F. Almeida, Nelson P. Rocha, and Anabela G. Silva, ‘Methodological Quality of Manuscripts Reporting on the Usability of Mobile Applications for Pain Assessment and Management: A Systematic Review’, Int. J. Environ. Res. Public. Health, vol. 17, no. 3, p. 785, Jan. 2020. DOI: 10.3390/ijerph17030785 [32] H. Breivik, P.C. Borchgrevink, S.M. Allen, L.A. Rosseland, L. Romundstad, E.K. Breivik Hals, G. Kvarstein, and A. Stubhaug, ‘Assessment of pain’, Br. J. Anaesth., vol. 101, no. 1, pp. 17–24, Jul. 2008. DOI: 10.1093/bja/aen103 [33] Ronald Melzack, ‘The McGill Pain Questionnaire: Major properties and scoring methods’, PAIN, vol. 1, no. 3, pp. 277–299, Sep. 1975. DOI: 10.1016/0304-3959(75)90044-5 [34] Gillian A. Hawker, Samra Mian, Tetyana Kendzerska, and Melissa French, ‘Measures of adult pain: Visual Analog Scale for Pain (VAS Pain), Numeric Rating Scale for Pain (NRS Pain), McGill Pain Questionnaire (MPQ), Short-Form McGill Pain Questionnaire (SF-MPQ), Chronic Pain Grade Scale (CPGS), Short Form-36 Bodily Pain Scale (SF-36 BPS), and Measure of Intermittent and Constant Osteoarthritis Pain (ICOAP)’, Arthritis Care Res., vol. 63, no. S11, pp. S240–S252, Nov. 2011. DOI: 10.1002/acr.20543 [35] Ronald Melzack, ‘The short-form McGill pain questionnaire’, Pain, vol. 30, no. 2, pp. 191–197, Aug. 1987. DOI: 10.1016/0304-3959(87)91074-8 [36] Amelia Williamson and Barbara Hoggart, ‘Pain: a review of three commonly used pain rating scales’, J. Clin. Nurs., vol. 14, no. 7, pp. 798–804, Aug. 2005. DOI: 10.1111/j.1365-2702.2005.01121.x [37] Mark P. Jensen, Judith A. Turner, and Joan M. Romano, ‘What is the maximum number of levels needed in pain intensity measurement?’, PAIN, vol. 58, no. 3, 1994 [Online]. Available: https://journals.lww.com/pain/Fulltext/1994/09000/What_is_the_maximum_number_of_levels_needed_in.11.aspx [38] Jin-shei Lai, Kelly Dineen, Bryce B Reeve, Jamie Von Roenn, Daniel Shervin, Michael McGuire, Rita K Bode, Judith Paice, and David Cella, ‘An Item Response Theory-Based Pain Item Bank Can Enhance Measurement Precision’, J Pain Symptom Manage, vol. 30, no. 3, pp. 278–288, 2005. DOI: 10.1016/j.jpainsymman.2005.03.009 [39] Nicolas Bourdel, João Alves, Gisele Pickering, Irina Ramilo, Horace Roman, and Michel Canis, ‘Systematic review of endometriosis pain assessment: how to choose a scale?’, Hum. Reprod. Update, vol. 21, no. 1, pp. 136–152, Jan. 2015. DOI: 10.1093/humupd/dmu046 [40] K.O. Biberoglu and S.J. Behrman, ‘Dosage aspects of danazol therapy in endometriosis: Short-term and long-term effectiveness’, Am. J. Obstet. Gynecol., vol. 139, no. 6, pp. 645–654, Mar. 1981. DOI: 10.1016/0002-9378(81)90478-6 [41] Katy Vincent, Stephen Kennedy, and Pamela Stratton, ‘Pain scoring in endometriosis: entry criteria and outcome measures for clinical trials. Report from the Art and Science of Endometriosis meeting’, Fertil. Steril., vol. 93, no. 1, pp. 62–67, Jan. 2010. DOI: 10.1016/j.fertnstert.2008.09.056 [42] Christoph Gerlinger, Ulrike Schumacher, René Wentzeck, Kerstin Uhl-Hochgräber, Erich Solomayer, Heinz Schmitz, Thomas Faustmann, and Christian Seitz, ‘How can we measure endometriosis-associated pelvic pain?’, J. Endometr., vol. 4, pp. 109–116, Oct. 2012. DOI: 10.5301/JE.2012.9725 [43] Elena Fabbri, Gioia Villa, Mohamed Mabrouk, Manuela Guerrini, Giulia Montanari, Roberto Paradisi, Stefano Venturoli, and Renato Seracchioli, ‘McGill Pain Questionnaire: A multi-dimensional verbal scale assessing postoperative changes in pain symptoms associated with severe endometriosis’, J. Obstet. Gynaecol. Res., vol. 35, no. 4, pp. 753–760, Aug. 2009. DOI: 10.1111/j.1447-0756.2008.00994.x [44] Jennifer Droz and Fred M. Howard, ‘Use of the Short-Form McGill Pain Questionnaire as a Diagnostic Tool in Women with Chronic Pelvic Pain’, J. Minim. Invasive Gynecol., vol. 18, no. 2, pp. 211–217, Mar. 2011. DOI: 10.1016/j.jmig.2010.12.009 41

[45] Karen Ballard, Hazel Lane, Gernot Hudelist, Saikat Banerjee, and Jeremy Wright, ‘Can specific pain symptoms help in the diagnosis of endometriosis? A cohort study of women with chronic pelvic pain’, Fertil. Steril., vol. 94, no. 1, pp. 20–27, 2010. [46] Ellen A.A. Jaatun and Martin Gilje Jaatun, ‘Advanced Healthcare Services Enabled by a Computerized Pain Body Map’, 7th Int. Conf. Emerg. Ubiquitous Syst. Pervasive Netw. EUSPN 2016 6th Int. Conf. Curr. Future Trends Inf. Commun. Technol. Healthc. ICTH-2016Affiliated Workshop, vol. 98, pp. 251–258, Jan. 2016. DOI: 10.1016/j.procs.2016.09.040 [47] Diana J Wilkie, M.Kay M Judge, Donna L Berry, Jean Dell, Shiping Zong, and Rudy Gilespie, ‘Usability of a Computerized PAINReportIt in the General Public with Pain and People with Cancer Pain’, J. Pain Symptom Manage., vol. 25, no. 3, pp. 213–224, Mar. 2003. DOI: 10.1016/S0885-3924(02)00638-3 [48] T. Serif and G. Ghinea, ‘Recording of time-varying back-pain data: a wireless solution’, IEEE Trans. Inf. Technol. Biomed., vol. 9, no. 3, pp. 447–458, Sep. 2005. DOI: 10.1109/TITB.2005.847514 [49] G. Ghinea, F. Spyridonis, T. Serif, and A. O. Frank, ‘3-D Pain Drawings–-Mobile Data Collection Using a PDA’, IEEE Trans. Inf. Technol. Biomed., vol. 12, no. 1, pp. 27–33, Jan. 2008. DOI: 10.1109/TITB.2007.903266 [50] F. Spyridonis and G. Ghinea, ‘A pilot study to examine the relationship of 3D pain drawings with objective measures in mobility impaired people suffering from low back-pain’, in 2010 Annual International Conference of the IEEE Engineering in Medicine and Biology, 2010, pp. 3895–3898. DOI: 10.1109/IEMBS.2010.5627668 [51] Tor-Morten Grønli, Gheorghita Ghinea, and Fotis Spyridonis, ‘A Mobile Visual Diary for Personal Pain Management’, in Digital Human Modeling. Applications in Health, Safety, Ergonomics and Risk Management: Ergonomics and Health, Cham, 2015, pp. 435–440. [52] Robert N. Jamison, Tabitha A. Washington, Padma Gulur, Gilbert J. Fanciullo, John R. Arscott, Gregory J. McHugo, and John C. Baird, ‘Reliability of a Preliminary 3-D Pain Mapping Program’, Pain Med., vol. 12, no. 3, pp. 344–351, Mar. 2011. DOI: 10.1111/j.1526-4637.2010.01049.x [53] Chitra Lalloo and James L Henry, ‘Evaluation of the Iconic Pain Assessment Tool by a Heterogeneous Group of People in Pain’, Pain Res. Manag., vol. 16, p. 463407, 2011. DOI: 10.1155/2011/463407 [54] Amy Jang, Diana L. MacLean, and Jeffrey Heer, ‘BodyDiagrams: Improving Communication of Pain Symptoms through Drawing’, in Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, New York, NY, USA, 2014, pp. 1153–1162 [Online]. DOI: 10.1145/2556288.2557223 [55] Ellen Anna Andreassen Jaatun, Dagny Faksvåg Haugen, Yngve Dahl, and Anders Kofod-Petersen, ‘Designing a reliable pain drawing tool: avoiding interaction flaws by better tailoring to patients’ impairments’, Pers. Ubiquitous Comput., vol. 19, no. 3, pp. 635–648, Jul. 2015. DOI: 10.1007/s00779-015-0850-3 [56] Fani Gkrozou and Natasha Waters, ‘A Preliminary Review of the mHealth Apps Focused in Endometriosis and Chronic Pelvic Pain’, Health Sci. J., vol. 13, no. 3, 2019. DOI: 10.36648/1791-809X.1000656 [57] ‘JavaScript’, MDN Web Docs. [Online]. Available: https://developer.mozilla.org/en-US/docs/Web/JavaScript. [Accessed: 14-Dec-2020] [58] ‘JavaScript modules’, MDN Web Docs. [Online]. Available: https://developer.mozilla.org/en- US/docs/Web/JavaScript/Guide/Modules. [Accessed: 14-Dec-2020] [59] ‘Functions’, MDN Web Docs. [Online]. Available: https://developer.mozilla.org/en- US/docs/Web/JavaScript/Guide/Functions. [Accessed: 14-Dec-2020] [60] ‘Object prototypes’, MDN Web Docs. [Online]. Available: https://developer.mozilla.org/en- US/docs/Learn/JavaScript/Objects/Object_prototypes. [Accessed: 14-Dec-2020] [61] ‘Classes’, MDN Web Docs. [Online]. Available: https://developer.mozilla.org/en- US/docs/Web/JavaScript/Reference/Classes. [Accessed: 14-Dec-2020] [62] ‘JSON’, MDN Web Docs. [Online]. Available: https://developer.mozilla.org/en-US/docs/Glossary/JSON. [Accessed: 14- Dec-2020] [63] ‘JSON’. [Online]. Available: https://www.json.org/json-en.html. [Accessed: 14-Dec-2020] [64] ‘The V8 JavaScript Engine’, The V8 JavaScript Engine. [Online]. Available: https://nodejs.dev/. [Accessed: 14-Dec- 2020] [65] ‘About npm | npm Docs’. [Online]. Available: https://docs.npmjs.com/about-npm. [Accessed: 14-Dec-2020] [66] ‘Event loop: microtasks and macrotasks’. [Online]. Available: https://javascript.info/event-loop. [Accessed: 14-Dec-2020] [67] ‘Promise’, MDN Web Docs. [Online]. Available: https://developer.mozilla.org/en- US/docs/Web/JavaScript/Reference/Global_Objects/Promise. [Accessed: 14-Dec-2020] [68] ‘Introduction to the DOM - Web APIs | MDN’. [Online]. Available: https://developer.mozilla.org/en- US/docs/Web/API/Document_Object_Model/Introduction. [Accessed: 14-Dec-2020] [69] Akshat Paul and Abhishek Nalwaya, ‘Learning the Basics: A Whistle-Stop Tour of React’, in React Native for Mobile Development: Harness the Power of React Native to Create Stunning iOS and Android Applications, [Online]. Available: https://learning.oreilly.com/library/view/react-native-for/9781484244548/html/346704_2_En_1_Chapter.xhtml. [Accessed: 14-Dec-2020] [70] ‘Components and Props – React’. [Online]. Available: https://reactjs.org/docs/components-and-props.html. [Accessed: 14-Dec-2020] [71] ‘Hooks at a Glance – React’. [Online]. Available: https://reactjs.org/docs/hooks-overview.html. [Accessed: 14-Dec-2020] 42

[72] Parashuram N, React Native’s New Architecture - Parashuram N - React Conf 2018. 2018 [Online]. Available: https://www.youtube.com/watch?v=UcqRXTriUVI. [Accessed: 14-Dec-2020] [73] ‘Frame rate - Firefox Developer Tools | MDN’. [Online]. Available: https://developer.mozilla.org/en- US/docs/Tools/Performance/Frame_rate. [Accessed: 14-Dec-2020] [74] Declarative future of gestures and animations in React Native - Krzysztof Magiera (@kzzzf). 2018 [Online]. Available: https://www.youtube.com/watch?v=kdq4z2708VM. [Accessed: 01-Dec-2020] [75] ‘Jank - MDN Web Docs Glossary: Definitions of Web-related terms | MDN’. [Online]. Available: https://developer.mozilla.org/en-US/docs/Glossary/Jank. [Accessed: 14-Dec-2020] [76] Janic Duplessis, ‘Using Native Driver for Animated’, 14-Feb-2017. [Online]. Available: https://reactnative.dev/. [Accessed: 14-Dec-2020] [77] ‘About React Native Reanimated | React Native Reanimated’. [Online]. Available: https://docs.swmansion.com/react- native-reanimated//react-native-reanimated/docs/1.x.x/about. [Accessed: 14-Dec-2020] [78] ‘Gesture Responder System · React Native’. [Online]. Available: https://reactnative.dev/docs/gesture-responder-system. [Accessed: 14-Dec-2020] [79] ‘PanResponder · React Native’. [Online]. Available: https://reactnative.dev/docs/panresponder. [Accessed: 14-Dec-2020] [80] React Conferences by GitNation, React Native Touch & Gesture - Krzysztof Magiera. 2017 [Online]. Available: https://www.youtube.com/watch?v=V8maYc4R2G0. [Accessed: 01-Dec-2020] [81] ‘About Gesture Handlers | React Native Gesture Handler’. [Online]. Available: https://docs.swmansion.com/react-native- gesture-handler/docs/about-handlers. [Accessed: 14-Dec-2020] [82] Per Runeson and Martin Höst, ‘Guidelines for conducting and reporting case study research in software engineering’, Empir. Softw. Eng., vol. 14, no. 2, p. 131, Dec. 2008. DOI: 10.1007/s10664-008-9102-8 [83] Robert K Yin, Case study research : design and methods, 3 ed.. Thousand Oaks: Thousand Oaks : Sage Publications, 2003. [84] Robert Davison, Maris G. Martinsons, and Ned Kock, ‘Principles of canonical action research’, Inf. Syst. J., vol. 14, no. 1, pp. 65–86, Jan. 2004. DOI: 10.1111/j.1365-2575.2004.00162.x [85] Miroslaw Staron, ‘Introduction’, in Action Research in Software Engineering: Theory and Applications, M. Staron, Ed. Cham: Springer International Publishing, 2020, pp. 1–13 [Online]. DOI: 10.1007/978-3-030-32610-4_1 [86] Peter Reason and Hilary Bradbury, The SAGE handbook of action research : participative inquiry and practice, 1st ed. Los Angeles, [Calif.]: Los Angeles, Calif., 2001. [87] Miroslaw Staron, ‘Action Research as Research Methodology in Software Engineering’, in Action Research in Software Engineering: Theory and Applications, M. Staron, Ed. Cham: Springer International Publishing, 2020, pp. 15–36 [Online]. DOI: 10.1007/978-3-030-32610-4_2 [88] Colin Robson, Real world research : a resource for social scientists and practitioner-researchers, 2. ed.. Oxford: Oxford : Blackwell, 2002. [89] Louis Menand, Pragmatism: A Reader. New York, NY, USA: Vintage Press, 1997. [90] RE Stake, The Art of Case Study Research. Sage, 1995. [91] Timothy Lethbridge, Susan Sim, and Janice Singer, ‘Studying Software Engineers: Data Collection Techniques for Software Field Studies’, Empir. Softw. Eng., vol. 10, pp. 311–341, Jul. 2005. DOI: 10.1007/s10664-005-1290-x [92] Jean Anastas and Marian MacDonald, Research Design for Social Work and the Human Services, 2nd ed. New York: Lexington, 1994. DOI: 10.7312/anas11890 [93] M. Shaw, ‘Writing good software engineering research papers’, in 25th International Conference on Software Engineering, 2003. Proceedings., 2003, pp. 726–736. DOI: 10.1109/ICSE.2003.1201262 [94] Xiaofeng Wang, Kieran Conboy, and Oisin Cawley, ‘“Leagile” software development: An experience report analysis of the application of lean approaches in agile software development’, Spec. Issue Agile Dev., vol. 85, no. 6, pp. 1287–1299, Jun. 2012. DOI: 10.1016/j.jss.2012.01.061 [95] Kieran Conboy, ‘Agility from First Principles: Reconstructing the Concept of Agility in Information Systems Development’, Inf. Syst. Res., vol. 20, no. 3, pp. 329–354, 2009. [96] ‘Manifesto for Agile Software Development’, 2001. [Online]. Available: https://agilemanifesto.org/. [Accessed: 12-Oct- 2020] [97] Martin Fowler and Jim Highsmith, ‘The Agile Manifesto’, p. 7. [98] Taiichi Ohno, Toyota production system: beyond large-scale production. crc Press, 1988, ISBN: 0-915299-14-3. [99] Mary Poppendieck, Lean software development : an agile toolkit. Boston: Boston : Addison-Wesley, 2003. [100]Dai Clegg and Richard Barker, Case Method Fast-Track: A Rad Approach. USA: Addison-Wesley Longman Publishing Co., 1994. [101] ‘Conferences – React’. [Online]. Available: https://reactjs.org/community/conferences.html. [Accessed: 16-Dec-2020] 43

Appendix: Code highlights

GitHub link to prototype source code: https://github.com/albran/paintrack

Screen navigation

The app consists of three parent screens, a ‘draw’, a ‘calendar’ screen and a ‘tutorial’ modal, with the tutorial modal possessing three child tabs for tutorial screens. Navigation is handled by the third party React Navigation package using stack navigator design. Stack navigation history is represented by a stack of screens, when a new screen is accessed it is pushed to the stack and navigating backward causes screens to be popped from the stack. React Navigation implements navigation in code by providing a NavigationContainer root component and separate methods for initializing navigation components of different types which are then nested within NavigationContainer. Calling initializer methods returns an object with properties for creating components that represent screens and navigators.

Figure 17: Navigation logic in App.js 44

Navigation in the app consists of a child tab navigator and stack navigator nested inside a parent stack navigator (see Figure 17, p. 43). The MainStackNavigator and ModalTabNavigator methods in App.js generate the child navigators for the draw and calendar screen stack and the tutorial tab stack respectively. These child navigators are passed as screens to the root navigator, forming a navigation tree with a depth of 2.

Draw UI state

The Draw component in Draw.js is the root component for the screen that displays the CPBM and tooltip. UI state is managed with useState hook variable drawState and setDrawState method along with a global DrawStates enumeration specified in globals.js. There are 10 enumerated draw states representing 10 unique UI configurations, and drawState is updated by calling setDrawState with one of the enumerated states from the global DrawStates object (see Figure 18). The Tooltip component observes drawState using comparison operators to display child components that correlate to each UI state.

Figure 18: Enumeration of view states for the Draw UI. Canvas implementation

The Canvas component in Canvas.js is the root component that owns all state and logic for the CPBM display. The Canvas UI is implemented using the Scalable Vector Graphic (SVG) image format provided by the React Native SVG package. SVGs are designed to display shapes consistently at any scale and are defined using XML.

React Native SVG provides an Svg component which defines the window dimensions within which different types of SVG shapes are drawn. Shapes are implemented using corresponding component types that are nested within the parent Svg component. The Svg window size is scaled to occupy the same percentage of screen height across devices. This is achieved by obtaining device-specific window height and width from the React Native useWindowDimensions API and applying mathematical constants obtained through manual testing.

The model of the pelvis is represented by the Model component implemented in Model.js. The root component in Model is a G or ‘group’ component that is used to group together shape components 45

that share common properties. Path components are used to draw the front and back outlines of the model. These take a ‘draw’ or d property that specifies a list of coordinate-based instructions for drawing strokes.

Canvas owns state variables that determine model appearance, state variables that determine pain stroke width and path, callback functions for gesture events, and reference variables for animation of the width circle. Model consumes the state variables viewIsFront and depth which it uses to display the corresponding SVG Path component for either front or back views and the corresponding opacity. The onSwipeHandlerStateChange and onTapHandlerStateChange gesture handlers in Canvas call setViewIsFront and setDepth each time a corresponding gesture event is completed in order to update Model (see Figure 19).

Figure 19: Gesture handlers in Canvas (left) are used to update the view of Model (right).

The animated circle outline that responds to a pinch gesture for selecting stroke width is implemented using a natively animated SVG Circle component. The onPinchGestureEvent handler in Canvas (see Figure 20) produces a native animation event that consumes data from a native pinch gesture event to dynamically update the scale and focal coordinates of the circle. A side effect callback with a listener variable sends the scale value to the JS realm which is used to set the stroke width. The onPinchHandlerStateChange manages a state boolean variable setCircleIsVisible which only displays the animated circle while the pinch gesture handler is in an active state.

Figure 20: Declaration of circle variables (left), manipulation of variables by gesture handlers (centre) and display of AnimatedCircle (right) in Canvas. 46

The animation of strokes while drawing is handled in the JS realm by the onDrawGestureEvent function which manipulates a pathRef reference variable and a livePath state variable within Canvas. onDrawGestureEvent updates livePath by pushing screen coordinates captured from native pan gesture events to a pathRef reference variable before passing pathRef to setLivePath. This procedure updates livePath and triggers reconciliation and rerendering with every new coordinate received from the pan gesture handler. The onDrawHandlerStateChange function resets the pathRef array on the beginning of each new pan gesture event.

Gesture handling

Gesture logic is handled by the third party React Native Gesture Handler package which provides components for capturing a variety of gesture types. Gesture handlers operate as state machines that move between six states: undetermined, failed, began, cancelled, active and end. Each handler can receive callback functions that determine logic to be triggered either on state change or continuously during the active state.

The app uses combinations of tap, pan and pinch gestures across different draw states. Tap and swipe gesture handlers are active while navigating between views and depths and pressing on existing pain strokes, a pinch gesture handler is active when adjusting stroke width, and a pan gesture handler is active when drawing pain strokes. The GesturesHandler component detailed in GesturesHandler.js wraps the Svg component within Canvas and inserts the correct gesture handler depending on the draw state (see Figure 21, p. 47). Callbacks for the handling of gesture logic are declared as closures within Canvas and passed down to GesturesHandler as props.

Gesture handler functions consume event objects that contain data relevant to processing the event in question. Event objects are produced by coded animation events or received directly from corresponding gesture events via callbacks. Event objects encapsulate native event data on the nativeEvent property. Gesture events attach their state to the nativeEvent object which can then be observed within gesture handler functions.

47

Figure 21: Conditional insertion of gesture handlers in GesturesHandler.

48

Stroke data model and styling

The stroke data model is encapsulated in a state variable named liveStroke and managed by the dispatch function updateLiveStroke. The reducer function liveStrokeReducer detailed in reducers.js (see Figure 22) and an initial state of null are used to create liveStroke and updateLiveStroke within Draw, which passes them down to child components that are updated by and update state respectively.

Figure 22: Reducer for managing liveStroke.

Figure 23: Examples of actions used with the dispatch function updateLiveStroke.

New liveStroke objects are initialized in Canvas by onDrawHandlerStateChange when the gesture handler state is ending, which uses an action object to pass in the stroke path and width variables as well as view and depth settings of the CPBM model (see Figure 23, left). Tooltip child components append properties to liveStroke by passing action objects to updateLiveStroke via UI event callbacks (Tag/Tag.js, RadioButton/RadioButton.js, PatternButton/PatternButton.js, Note/Note.js). StrokeInfo calls updateStrokes via the saveStroke callback passed down from Draw to append a copy of liveStroke to strokes, after which it calls updateLiveStroke to null the liveStroke reference in preparation input of the next stroke.

Strokes are saved in application memory using the stateful array variable strokes which is managed by the updateStrokes dispatch function (see Figure 24, p. 49 for the associated reducer). The Draw component calls updateStrokes when loading a collection of strokes from async storage, when saving a new stroke, or when deleting a stroke. 49

Figure 24: Reducer for managing in-memory strokes array.

Stroke appearance is managed by Stroke and StrokesRenderer which use properties from stroke objects to determine style (see Figure 25). Stroke encapsulates SVG Polyline components that receive a string prop points detailing coordinates which are used to draw paths in the coordinate space defined by the parent Svg component. While drawing strokes, Stroke receives coordinates from the dynamically updated livePath variable, otherwise it reads static coordinates from the liveStroke object that is created after drawing. The style of the animated stroke displayed while drawing is determined by default parameters in Stroke, and once liveStroke has been created Stroke infers styles from the properties of its data model. StrokesRenderer is responsible for displaying drawn strokes by mapping stroke objects from the in-memory strokes array to Stroke components. StrokesRenderer compares the depth and viewIsFront state variables of Canvas to the corresponding properties in each stroke object to only display strokes that were drawn at a given

Figure 25: Strokes (left) and StrokesRenderer (right). 50 depth and view. In the navigation draw state, StrokesRenderer also passes a callback to the onPress prop of the Polyline component in each Stroke which changes the view state and calls updateLiveStroke. This causes pressed strokes to be set as liveStroke which is read by StrokeInfo in order to display the properties of the selected stroke on screen.

Factors data model and styling

The factors data model is encapsulated in the factors state variable and managed by the updateFactors dispatch function. The initial factors state is informed by the factorsInitialState object detailed in reducers.js (see Figure 26). Both factors and updateFactors are passed down to the child components of Factors.

Figure 26: Reducer for managing factors object and initial state object.

The child components of Factors (FactorButton, BleedScale and BleedButton) use a combination of useState and useEffect hooks to manage state and appearance. Factors maps each FactorButton from a labels array and passes updateFactors as a prop. FactorButton uses selected and setSelected to toggle its state and appearance between two settings via a press event callback, with initial state being loaded from the factors object during the first render via a useEffect hook. A separate useEffect hook monitors selected and calls updateFactors when it changes state.

The BleedScale component owns a selected state that is shared between three BleedButton children that are mapped from a bleedValue array. State of selected is initialized with a useEffect callback in BleedScale and has 7 possibilities that are set by BleedButton via calling setSelected on a press event. BleedScale uses a separate useEvent callback that monitors selected in order to call updateFactors.

Persistence

Factor and stroke data are saved in device memory with the assistance of the third party AsyncStorage package. AsyncStorage provides an asynchronous API that allows saving and loading 51 of data using string key-value pairs, where values are serialized JSON strings. The persistence data model uses a formatted date string as a key that points to an object value containing a strokes array property and a factors object property. The default date key is derived from the current date and created in App.js from a JS Date object using the formatting function getYYYYMMDD. App.js encapsulates date keys in the state variable date and passes setDate down to Calendar. Draw receives date from app and owns the callbacks that process persistence logic.

Strokes and factors are saved in the saveStroke and saveFactors methods that call mergeItem method of AsyncStorage, which only overrides specified properties of the stored object of a given key. Strokes are deleted from the strokes array property by filtering the in-memory strokes array before passing it to setItem which overrides the value of a given key. To preserve consistency between stored and in-memory data, all mutations within the app are first updated in storage before being updated in-memory.

Strokes and factors are loaded from storage by the function getDate nested in a useEffect callback in Draw which is called every time date changes state. This is triggered when a date is selected in Calendar which calls setDate. If no data exists for a given date key, the useEffect callback calls updateStrokes and updateFactors to initialize new strokes and factors instances.

The getDay function uses a date state variable as a string key to retrieve existing data from async storage and returns null if a particular date key does not exist in storage. The useEffect hook calls getDay every time the date state variable is updated, either automatically by App.js whenever the application is opened, or via Calendar calling setDate when a particular date is pressed (see Figure 27). After calling getDay, useEffect populates in-memory data structures with retrieved data, or initializes new structures if null is return

Figure 27: The useEffect hook in Draw that calls getDay. 52

TRITA-EECS-EX-2021:112

www.kth.se