Team profile and personal information

Annesha's personal profile

Connor's personal profile

Dominic's personal profile

Jared's personal profile

Trents's personal profile

As our team has completed a wide range of personality tests, this analysis will focus on the Myers-Briggs test results for each individual member. Within the Myer’s Briggs test there are four foundational personality groups: Analysts, Diplomats, Sentinels, and Explorers (Personality Types, 2022). As a team, the Awesome Breakfast Club is quite diverse, covering three of the four personality groups with Trent in the Explorer group, Connor and Jared as Diplomats, and Dominic and Annesha in the Sentinels group. This diversity in personality types means that as a group we have a variation of different attitudes, opinions and perspectives. In terms of communication, we have 60% Introverts and 40% Extroverts. With this mixture of introverts and extroverts, we will need to consciously make our meetings a safe space in which both introverts and extroverts have the space and time to express their thoughts with the group, so they do not go unheard. In practice this can mean proactively running our meeting with an agenda so that all members can come to the meeting prepared for discussion, and then within the meetings, ensuring that every member has a chance to voice their thoughts on the agenda items prior to proceeding with the next topics. As the team contains introverts, it’s important that we utilise these methodologies in practice encourage equal expression and involvement. Within the Myer-Briggs test results, the third and fourth letters letter of a personality type indicate a person’s decision-making techniques and their perception of their surroundings (Myers-Briggs personality type and conflict - what causes fights between MBTI types?, 2021). In analysing the personality types, both traits combined provide insight as to how individuals view and react to conflict. Of the four possible combinations for these pairs, the ABC team has three of the four combinations. The majority of the team have the traits Feeling and Judging (Annesha, Dominic and Jared), whilst Connor is Feeling and Perceiving, and Trent is Thinking and Perceiving. To summarise the different traits, Annesha, Dominic and Jared are likely to have conflict arise when their core beliefs are challenged, and will approach it in an extraverted way, discussing and resolving the conflict verbally (Myers-Briggs personality type and conflict - what causes fights between MBTI types?, 2021). As a Feeling and Perceiving type, Connor is likely to face conflict for the same reasons, however, is more likely to feel this conflict internally. Whist Trent is also likely to experience conflict internally, this conflict alternatively arises when trust and credibility are challenged (Myers-Briggs personality type and conflict - what causes fights between MBTI types?, 2021). In practice, the group can attempt to reduce conflict by being aware of the potential triggers for each member. For the FJ and FP types, one of the most important values is maintaining positive relationships and making sure all members feel heard. For the TP members of the group, it is important that trust is maintained and everyone’s credibility within the group is respected. By respecting each member’s values, the team will be able to uphold a strong level of productivity, reducing conflict and unease withing the team. In respecting each other’s values, beliefs and integrity, the team also creates a safe environment which encourages both creativity and cohesion.

Group Processes

In assignment 2 our group had good, regular communication, however at times we were hindered by our unfamiliarity with the new platforms we were learning such as Microsoft Teams and GitHub. This was overcome through practice and sharing of our experiences and understanding of the platforms. Another difficulty we faced in assignment 2 was conflicting busy schedules and time zone differences. We overcame this by keeping clear and regular communications regarding our availability and we tried to schedule meetings as often as possible to ensure that everyone was getting plenty of opportunity to be present. In assignment 2 we also found that communications were missed because of personal preferences for different communications platforms such as team's vs discord. In assignment 3, we have each made active efforts to ensure we are posting messages on all platforms and responding to all platforms to ensure that everyone is up to date with each other and that nothing is missed. We have made 2 major changes to our structure for assignment 3. Firstly, we have very early on communicated our expectations around the share of assignment work. This feedback has been well received across the group and significant efforts have been made by all members to ensure that no one is left to feel overwhelmed with assignment 3. The other considerable change we have made, is that we have split into two groups so that we can maintain focus and handle the concurrent requirements of both assignments 3 & 5. This has been successful so far and has allowed us to make good progress whilst not falling behind on other aspects of the unit.

Ideal Jobs comparison

The largest common element with all the jobs listed that we’ve chosen as our “Ideal Jobs” is that they all involve Computers and Information Technology in one aspect or another. Security Engineers, Cyber Security Analysts and Cyber Analysts play very similar roles to one another; keeping the systems they’re in charge of secure from outside threats and ensuring those systems are up to scratch. All three analyst jobs involve going over data and dictating non-urgent tasks over to the appropriate teams to be taken care of in multiple areas.

Career Plans comparison

Annesha's’ career plan to achieving her ideal job is to study and improve on her skills and specific requirements of her desired position as well as working alongside tenured technical business analysts. This aligns with Dominics career plan, which is to improve upon his skills and hone them while applying for an internship so that he can gain the experience needed for the role by learning from professionals. Dominic also has a plan to find alternative ways of gaining experience with specific tools of the industry in case the internship doesn’t cater to the exact requirements of his ideal job. This contrasts with Jared and Connors approach, who’s goals are to achieve their ideal jobs by completing the required tertiary qualifications. Connor intends to do this by studying IT and improving on his skills until they are considered sufficient by potential employers. Jared, however, can enter his career without any qualifications, though he intends to study IT and improve his employability for the competitive position and to prepare himself for the work which it requires. Trent does not have a career plan, but his initial goals are to complete tertiary study of IT in order to gain skills necessary for his ideal job. Trent, Jared, and Connor share their interest in cyber security with their ideal jobs only slightly varied in role title. This leads them to have similar career plans with only slight differences between them. Through our different approaches there are some comparable decisions made, most notably we have all decided to complete tertiary study and improve upon our skills. Each member understands that rather than doing the bare minimum and hoping for the best, to become competitive in our chosen ideal jobs we must strive to improve and continue our learning.

Tools

Group Github links

Group Repository link: Available here

Group Website link: Available here

Personal GitHub Links

Annesha: Personal profile available here

Connor: Not available

Dominic: Personal profile available here

Jared: Personal profile available here

Trent: Not available

Meetings

11.08.2022 - Agenda Recording Actions

14.08.2022 - Agenda Recording Actions

16.08.2022 - Agenda Recording Actions

Project description

Topic

For our IT Project Idea, the Awesome Breakfast Club Group have developed an application for mobile and wearable devices which allows users experiencing chronic pelvic pain symptoms to easily record the pain from their Smart Watch. This application will aim to assist users and their specialists in establishing a quicker diagnosis of pelvic pain disorders, by giving users an accurate and convenient way to record their pain. Reaching a diagnosis for chronic pelvic pain conditions can be a long and arduous process, often requiring patients to keep a detailed log of the pain and symptoms. This watch application provides users with an easily accessible method of recording a patient’s pain and symptoms in daily life from the watch face. In the long term, this application can be used to assist in the diagnosis and treatment of common pelvic pain disorders such as Endometriosis, Adenomyosis, and polycystic ovarian syndrome (PCOS).

Rather than having to pause activities to record their pain symptoms, this application will allow users to simply record their pain level and frequency from the home screen of their Smart Watch, tablet, and Smart phone. All these records are then stored within a secure cloud database, which can be downloaded and reviewed in a consultation with their health professional to uncover any trends. In order to allow sufficient trend analysis, this application allows multiple pain records to be entered for a single day, as this can be beneficial in establishing whether the pain is related to certain activities, such as eating or exercising.

Motivation

Annesha’s Journey to Diagnosis

“Since the age of 13 I have experienced frequent pelvic pain. In the following eight years I received many misdiagnoses and had multiple agonizing trips to the emergency room which left doctors baffled. In the end, my diagnosis took nine years and multiple surgeries. Personally, this long process was a frustrating and a very tiring one, as I was constantly needing to convince doctors of the severity and frequency of the pain. I think having a tool to easily record my pain could have helped to speed up the diagnosis process by quickly establishing trends in the pain occurrences.”

Our motivation as team has come from both firsthand personal experience and witnessing the struggles of our loved ones experiencing chronic pelvic pain.

Unfortunately, stories like Annesha’s are all too common, being diagnosed with the chronic pelvic pain conditions, such as Endometriosis, Adenomyosis and PCOS, is often a long and time-consuming process, requiring regular specialist appointments, treatment trials and even laparoscopic diagnostic Surgery. On average an Endometriosis diagnosis can take approximately seven years to diagnose from the onset of symptoms (AIHW, 2019). In these seven years, patients are likely to see many different specialists to establish pattern in their pain symptoms and eventually to diagnose their chronic pain. According to Lone Hummelshoj, Chief executive of the Endometriosis Research Foundation, one of the primary reasons for this lengthy diagnosis period, is the normalisation of painful periods (Dysmenorrhea) (Broster 2020). In conjunction with normalised Dysmenorrhea, delays in diagnosis can also be caused by the overlap of Endometriosis symptoms with other gynaecologic and gastrointestinal diseases (Surrey et al, 2020).

In diagnosing Endometriosis, some of the most common questions patients receive from their specialist are “How often do you get this pain?” and “When and where do you get this pain?”. However, when patients experience painful cramps daily, it’s common for the patient to feel ill-equipped to answer these questions or embarrassed, often resulting in vague and inaccurate answers, depicting non-specific symptoms (Surrey et al., 2020). By equipping patients with a tool to accurately record their pain symptoms immediately at the time of experiencing them, patients are empowered to provide their doctors with accurate information. In providing this resource, it is hoped that doctors will have more information available about the patient’s symptoms to determine if it is mild Dysmenorrhea, or something more serious like Endometriosis, Adenomyosis or PCOS. This application can also be used after diagnosis to track a patient’s progress when receiving treatments, for doctors to evaluate if treatments are effectively reducing pain.

Landscape

Over the years various methods have been used to record pain diaries, including paper diaries, mobile note applications and in recent years pain diary apps. With the introduction of pain diary apps in recent year, like QENDO, users can record the pain and symptoms for medical usage (QENDO 2020). These apps have been revolutionary in providing convenient ways for patients to record the symptoms; however, they often use tedious user interfaces which mean that completing the diary entries can take much longer than they need to. Today, wearable technologies are now a relatively common accessory in the form of Smart watches. This increased use of smart watches presents an opportunity to create a more convenient method of recording painful symptoms. In public situations where traditional pain diary logging is not a feasible option, or even in debilitating pain occurrences, this technology can provide a quick way of recording the occurrence, to ensure patients maintain an accurate record of their symptoms. In the first prototype of the application, by utilising a simple user interface on Smart Watches, users will be able to record their pain symptoms using Standard entry mode.

Aims

Our aim for this project is to create a pain management application that is compatible with smart phones and smartwatches. We will begin to do this by establishing a platform to create the application on. We will seek to find a cost-free platform with pre-built workflow actions, rather than having to learn to code, for a quicker and easier setup so that time limits can be met and issues due to inexperience minimised. The application must be compatible with mobile phones and smart watches. If the time limit does not allow for the implementation of smart watch usability the application must be viable for smart phones. While designing the application and the usability for the smart devices we aim to find a suitable database to work with storing and users' data. This will enable the results to be opened from the servers as a backup and an accessible information source for doctors who are treating the pain using the app. If the database was to fail at any point or we are unable to source a suitable one within the original time limit, the information will be stored and sourced locally via an ‘in-app’ database. This fall-back option also means that information can be stored locally when the database is under maintenance or inaccessible. After getting the initial functionality of the application working, we aim to create an attractive and efficient user interface so that the application will be a more friendly and appealing option for people to use. Our final goal is to link the original application from the software which we develop it to a popular application store (google play or apple store). This will allow it to be downloaded by users easily and stored on the smart device.

Plans and Progress

Our research for this project began with the basic steps of how to create an application because across the group we had no understanding of what was required or what products allow for the building of an application. We started by searching for similar apps and trying to find information on how these were built, but unfortunately had no luck. After that Dominic began looking for ways to build an app in general and came across a video on how to create a ‘timesheet application’ via ‘Microsoft Power Apps’ (Deasey, 2022). This seemed like a great place to start for us for a few reasons, first of all it provided a step-by-step process of how a basic application can be made, secondly it is financially viable because we all have free access to ‘Microsoft Office’ through our RMIT emails and finally, because our application is effectively a very basic form of timekeeping (for pain events).

Initial Prototype:

Our next step was to utilise ‘Microsoft Power Apps’ to build a prototype of our application so that we could start to gain an understanding of the requirements and systems that might be used for our final product. The tutorial video suggested a variety of data sources which we are compatible with ‘Power Apps’ but we decided to choose ‘Sharepoint’. We chose ‘Sharepoint’ because it is free with our RMIT email addresses, it is compatible with ‘Power Apps’ and it doesn’t require an extensive set up or knowledge to use it effectively.

The first step of creating the application was to organise the data source to a list/table style so that the columns represented the information titles, such as username, time of pain and level of pain. The username column was created as an ‘ID’ column. This records the users email address upon submission. The column for our time record was selected as a ‘date & time’ column and we turned on the feature which records the current time when the entry is created. The column for the ‘pain level’ was created as a ‘choice’ column. ‘Sharepoint’ allowed us to enter as many choices as we wanted for this column. We added 10 choices, in line with standard medical pain rating systems. The rows would then be populated with relevant detailed information each time data entry was submitted from the application. An important note at this stage is to remember the title names of chosen columns, because when we started building the app whilst watching the tutorial, the differences our title names and the tutorials title names caused confusion and added a considerable amount of time to the process.

The next step of the process was to start building the user interface of the application so that the records could be populated. When creating an application in ‘Power Apps’, it gives the format options of ‘Tablet’ or ‘Phone’. Since our application is being created to offer a quick response for people to record their pain and so, for the purposes of our prototype, we chose the phone as it is the most accessible option to our potential users. We then linked our data source ‘Sharepoint’ to the application, which made our columns available to be used in the application.

Our design was to have a simple, user friendly interface with minimal steps. To achieve this, we decided that the application needed a drop-down list of the 10 pain levels and a button to record that pain. To make the application intuitive, we put the pain level drop down list above the submit button so that it represented a top to bottom order of process. We had decided to make the colour theme the same as the website we had created.

Once the basic layout of the application was complete, we had to make the buttons functional. For the ‘record pain’ button, this meant we had to link a ‘patch’ function which, along with other abilities, creates records in our chosen data source. Whilst doing this, we add the required data to the patch such as user email and the pain level which the user selects from our drop-down list. We do this so that the app pulls all the information which we want to be recorded in our data source.

We tried to find an SDK application builder that would be more suitable to an open market. In our initial search we found one called XCode, which although would be suitable, it was limited to use on iOS devices and therefore reduces our potential market. After looking into it Bubble io seems to be a viable option for our needs and so we have decided to create the application on that platform.

Phone Application Prototype:

So, for the app development and design of the app we have found a pre-built site that allows us to design and program as we go at the same time as testing due to the lack of ability for me to type I will do my best to explain what I've gone through over the past few weeks

In the beginning it was a lot of just trial and error trying to find a website that allowed us to flesh out what we were looking for at first, we had looked at XCode and ... but then we found an application called Bubble.io. Unfortunately, it wasn’t an app we were able to use without an account so I took the sign-up process and continued to investigate finding whether this application would suffice.

Current Smart Watch Application Prototype:

Similar to the Mobile application prototype, the watch application prototype has been built using Bubble.io. Due to the limitations of Bubble.io, the initial smart watch prototype has been built in the same fashion as a mobile application in bubble.io, however the screen dimensions have been specified to match the dimensions of an Apple Watch.

The Prototype watch application has been built to initially open on the “Pain Entry” screen which displays with two buttons “Enter now” and “Remind Me Later”. When “Enter now” is selected, the “Intensity” screen displays with the prompt “Rate your pain on a scale of 1 (mild) to 10 (Worst):” and a drop-down selector ranging from one to ten, with an “OK” button displayed below. Once the user has selected the pain intensity score from the dropdown and selected “OK”, a confirmation screen then displays with the date and time of the entry and the intensity selected.

Alternatively, if the user selects the “Remind me Later” button on the “Pain Entry” screen, a confirmation screen will display with the message “Your entry at [Current date/time] has been saved. We will remind you via notification in 30 minutes to enter the intensity of the pain.”

In Bubble.io, all these pages have been built by first developing the visual aspects of the page such as text, buttons and dropdowns. Then once the user interface was completed, the workflows were created for each button by linking the action required to the relevant button which in turn displays desired information on the next page. As each page and workflow has been added, the components have been tested using the ‘Preview’ option in Bubble.io and debugging early in the development process.

Future plans for the application:

The next steps for developing the watch application are integrating the mobile and watch applications. By connecting the two applications to a single account, users will be able to log in to their account via their watch for a quick record and their mobile phone when appropriate to either expand on the brief record or to view previous records and identify ongoing trends.

Using Bubble.io, we will be able to build the application to be compatible for both Apple and Android devices. However, building the Smart Watch applications for release will require additional software as this is not currently a service provided by Bubble.io. The Android Smart Watch application will be built using a Wear OS project template in Android Studio, and then integrated with the mobile watch application (Android Developers 2022). The Apple version of the Smart Watch application will be built using Xcode and Swift UI (Apple Developer 2022).

Once the apps are developed and tested, it will initially be released to the public using Google Play Console to publish to the Google Play Store for Android devices (Google Play 2022). For our secondary release to Apple devices, we will submit the applications for review using App Store Connect, which upon approval can be published to the App Store (Apple Developer 2022).

Once released to the public, we will also be releasing regular updates to the application to improve functionality of the applications, such as adding cycle tracking, home screen widgets for Apple iOS, and a discrete app icon option.

Roles

We did not set specific roles for the design and development of our application because the app design program which we used, Bubble io, did not have a free option which allowed multiple users to edit the application remotely. This meant that only one person could be elected to physically develop the application. We often shared screens whilst Trent was working on our application so that we could all offer input to the user interface, application features and its functionality, this led to all group members contributing toward all roles required to create the application. We found that this method was also pertinent to the nature of the group assignment in that we were collaborating on all aspects of the application development.

Scope and limits

Our application is being created to improve the frequency which people suffering from undiagnosed chronic pain conditions record their pain, so that they can accurately report back to their GP in hopes of being diagnosed more quickly. To do this, we need to develop a record keeping application that is available and easy to use for our target audience even at the most inconvenient times.

This application therefore needs to have a seamlessly simple user interface which records the users ID in form of an email address, the time of their pain episode and the intensity of their pain. We aim to achieve this level by the time our assignment is due, but scope beyond this may include the ability to add specific notes to a pain record at a more convenient later date in order to improve feedback and face recognition log-in to improve user interaction.

In future updates to the application, we will introduce cycle tracking as an optional feature for the mobile application. As the application is supporting those experiencing chronic pelvic pain, which can have adverse effects on fertility (depending on the condition), it is important that the application prioritises pain management, rather than focusing on the user's fertility. For this reason, the Cycle Tracking feature will allow for ovulation and period tracking, but it will not focus on fertility and conception.

Utilising the knowledge of medical professional, future versions of the app will also provide users with insight as to how the frequency and intensity of their pain compares to standard period pain.

Tools and Technologies

Building our application required the use of many different tools and technologies for planning, prototyping and creating the final product. These tools and technologies have been listed and briefly explained below.

Sharepoint

Sharepoint is a table-based data point that stores information for users to review as needed. It was available to use via the Microsoft365 account associated with our RMIT email and so provided a cost-effective way for us to store information for our prototype. SharePoint is also easy to integrate with Microsoft Power Apps which was another important tool for our prototype.

Microsoft Power Apps

Power apps is a tool which allows creators to easily model user interfaces and code functionality of an application. This was a great starting point for our application as it was freely accessible through our RMIT email and associated office 365 account; it allowed us to create a basis for our user interface and it also gave us insight into ‘work flows’ or the coding of app functionality.

Bubble io

Bubble io is a ‘no-code’ application development tool that allows users with little to no experience build fully functional ‘Software as a Service’ applications and easily design efficient user interfaces. The free to use tool has pre-built work-flow functions which can be integrated into the users' applications rather than the laborious method of learning and writing the code that is required to create certain functions, such as recording time stamps or noting information. Bubble io also offers an in-app database to store information and integrates simple add-ons such as ‘login with Microsoft’ which outsources the storage of sensitive data like passwords and emails.

Microsoft Teams

Microsoft teams is a file sharing platform with communication abilities so that users can collaborate ideas when working on projects. We used its chat function to discuss our progress, to plan video meetings and to share resources. We utilised the video call function to screen share our active sessions and give each other feedback or ideas for development.

Testing

In Software testing there are four levels of testing; Component Testing, Integration Testing, System Testing, and Acceptance Testing (Reference ISTQB).

In the development of the prototype applications, we are using Component testing to verify the individual functionality of components such as buttons and fields. Once the individual components have been tested, we have then used Integration Testing to verify the different components function in isolation and together using the application workflow. Using Component and Integration testing early in the development process will reduce the presence of defects and bugs and reduce the time required for System Testing.

With the individual components and their integration tested in development, we can then move on to System Testing, which involves testing all the components together as a whole application. System Testing of the application prototype will require functional Blackbox testing. Functional Blackbox testing involves testing the user interface against the application requirements. As mentioned in the previous sections, the aim of the application is to allow users a quick method of entering their pain occurrences, so in this case some of our watch application requirements would include:

Group reflection

As a group there is a consensus that we have improved upon our processes and communication between assignments two and three. Consciously we have made changes to our communication strategies and established more channels of communication. These changes have allowed us to contact each other in urgent situations using discord and teams, as multiple team members already have discord on their computer and mobile. It is important to note that any formal work was still done in teams, but if we had an urgent question or notification; we could post this in discord so it would reach everyone promptly. Across the board, the team found assessment three to be much more manageable as the team were proactively involved in completing tasks early in the process and there was a more even spread of the workload.

There have been various recommendations for improvement within the team. These include setting deadlines for individual tasks to improve individual motivation and initiative, enhancing communication by establishing group goals, group knowledge share sessions to allow for growth within the team, and setting a clear procedure of what group members need to do when they require assistance. From experience, the issues behind these improvements did not present as critical blockers to the team's success, but rather presented obstacles for the team in the process.

Within our team there is a common thread amongst what aspects group members found surprising. In Assignment two, we faced challenges with communication and evenly spreading the workload amongst members. For many group members the surprising element of assignment three was how well we resolved these issues and worked together as team to put together the assignment. The changes were proactively made by openly discussing our feedback in a non-confrontational manner and opening lines of communication. Another surprising result which came from these efforts is a general sense of improvement in the quality of the work we produced with a more even workload.

Throughout the team there has been a mixture of learnings in assignment three. One unanimous learning across the team was the value of setting clear deadlines for individual tasks. Additionally, both Jared and Annesha learnt the value of knowledge sharing within the group to enable further professional development and growth.

In general, the group made lots of progress between completing assignment two and three. We did experience some difficulty with a team member struggling with motivation when the majority of the group were proactively working to distribute the workload evenly. Mostly we were able to overcome these obstacles with additional communication, and in turn functioned better as a proactive and productive team.

References