Milestone 3 🧪

Proposed level of achievement: Artemis.

What's new?

Milestone 3 brings exciting new features and many under-the-hood stability patches that improves overall user experience, and leverages BloodConnect from a minimum viable product in Milestone 2 to a more polished, completed product.

Smart search

The long waited smart search is finally here! Users will now be able to search through blood groups, location names, addresses, and request types (blood, plasma, or platelets) from the search box and the best part: it just works! There are no categorisations or additional buttons to control the search—the search algorithm will be able to determine the search category based on the search keywords. The search algorithm is also designed to be performant, and does not overload the CPU's stack frame despite its capabilities.

Over-the-air updates

Users will receive OTA updates, even without manually updating BloodConnect from the App Store or Play Store (if it is to be released). Once a bugfix or changes are deployed by the developers, all BloodConnect instances will automatically fetch and install the updates the next time the app is launched. For breaking changes, OTA updates will not automatically be installed, instead, will require the users to update manually from App Store or Play Store.

Realtime database: Single source of truth

Realtime database synchronisation was introduced in Milestone 2 and it was the main highlight of BloodConnect's aim to provide accurate information fast. In Milestone 3, we have refactored how realtime database synchronisation is structured with a hierarchical "single source of truth" and event listeners subscribing to changes fetched from the servers. This structure avoids redundant database queries, which saves servers cost, CPU performance, and improves overall UI stability. In addition, realtime changes can now be seen not only in the Requests sheet, but also in the map view, Manage requests, location cards, donation buttons, and View donors page. With this new structure, UI performance has seen a great boost and it will also be very easy to create new components which consume realtime database synchronisation.

Compatible blood groups filtering

Donors will now be able to see if they are compatible for a request from the new "Compatible blood groups" badges on every location cards. In addition, the blood group selection control in Donate screen now only views compatible blood groups. This will make it easier for donors to respond to a request, and also for blood seekers to find potential donors, as they are guaranteed that those who respond should be compatible.

General improvements

BloodConnect's code base has been upgraded to Expo SDK 38 and React Native 0.62. BloodConnect package size has greatly reduced by feeding on more built-in modules. UI components have also been refactored, and we have removed 5 redundant UI components while retaining the same good user interface. UI components are now more responsive, thanks to the new SDK and better structuring. Buttons are also now not susceptible to multiple invocations, so one tap at a time!

User authentication storage is now properly purged on every authentication state change, and BloodConnect is able to maintain authentication state persistence. Previously-entered user credentials are removed and navigation stacks are reset every time the state of the app changes.

important

The CVE-2020-8149 vulnerability involving logkitty version < 0.7.1 which allows arbitrary shell commands execution, were patched as of Milestone 3. Similarly, the recently released CVE-2020-8203 involving lodash version < 4.17.15 was also patched in Milestone 3.

Testing

Authorisation

  • Creating an account. We created a user account with a full name, email address, and password. As expected, the user was logged in and a verification email was sent. There was an issue whereby the authentication state was mutated and caused mix-ups and verification emails be sent to other users, and replaces the previous users' details. This issue has been fixed.

  • Logging in. We logged in with correct credentials, and the login was successful and the user's requests and details were correctly retrieved. Logging in with wrong credentials will lead to an error message, as expected.

  • Logging out. Upon logging out, we tried accessing screens which requires an authorised state, and the request failed, as expected. However, it was known that when logging in with a user (e.g. Alice), logging out, and logging in with another user (e.g. Bob), some screens were not re-rendered, leading to the old user's (Alice's) data being displayed. This issue can simply be resolved by ensuring proper purging after a logout and re-rendering screens after a successful login. We will create a service to perform these tasks, and deliver it in Milestone 3.

  • Creating an account with used email address led to an error. Passwords must also be at least 6 characters, as expected.

  • Exiting an app after logging in redirects user back to the Explore screen. If the user has signed out, the login screen is fresh, and tapping on back does not bring the user back to the Explore screen. The authentication state is fully purged after a sign-out and properly stored after a sign-in, all as expected.

Requests and donations

  • Donating to a request when it suddenly is closed elsewhere. This is one of a corner case, and when tapping on Submit, nothing happened. As expected, since the request status is not OPEN, the app returned an error log to the console. Now, instead of logging, the app will redirect users to a "Whoops!" screen which tells the user that the request has been closed and returns the user back to the Explore screen. This issue has been fixed.

  • Completing a request and returning back to Explore. If a user is viewing the location card of their own request and completes it, it was found that the location card was not dismissed, allowing the user to view the donors (if any) again and complete the request with another user. This is due to the fact that after completing a request, the navigation stack is popped only. Now, every time this happens, instead of popping the navigation stack, BloodConnect resets the whole navigation state. This is also one of a corner case, and has been fixed.

  • Closing a request and returning back to Explore. Same as above, but was only realised recently, and can simply be fixed with the same solution as above.

  • Opening a request details and using another device, completing it, simulating someone completing a request while the other is viewing. The marker on the map disappeared, while the location card persists. This can be fixed by subscribing the location card visibility property to the realtime database event listener.

  • Using long donor contact name pushes the request controls to the right, making the Call and Complete button not contained in the viewport. This issue has been fixed.

  • Choosing "Other blood groups" in New Request screen and not specifying anything in the description. We tested this behaviour, and it was "allowed". So, we added a validator to ensure blood seekers remember to provide a description when specifying "Other blood type". This issue has been addressed.

  • Blood type was uppercased in review request screen due to the use of same fields for id and label in Milestone 2. In Milestone 3, instead of a static string for blood types, we use a blood type object which is flexible and thus, we can show cleaner information in the Review request screen. This issue was addressed here and here.

Manage requests screen

  • While opening the view donors screen, remove all the donors from the database. The app would crash. And so, if the number of donors reduce to zero for a particular request, the view donors screen will just go back to the previous navigation stack. This issue was addressed here.

User testing

We tested BloodConnect with a select group of testers. Each user is given a unique Reserved Testing Account (RTA) that ends in @test.bloodwork.org and is given a set of tasks to complete. The tasks were completed in the expected period of time (creating a request and donating to a request, each takes on average 3 minutes and 12 seconds). The reception towards the user interface design was very satisfactory, with majority categorising it as "modern", "fresh" and "easy-to-use". The users were not given any instructions, and were left to their own devices to navigate through the UI and complete the tasks. Here are their selected feedback.

  • Add a time range to a request to add another criteria of "importance". This is a good suggestion, and in fact, was one of the intended feature in Milestone 1. We will implement this post-milestone 3.

  • Show the list of compatible blood groups. This is a very good suggestion, and in fact has been implemented as of this commit.

  • A confirmation screen after a requester completes a request. This is also a very good suggestion, and together with other "corner-case" fixes, was implemented as of this commit.

  • App crashed when viewing details of a request with Other blood group. This is a recently new development. We will continue to investigate this issue.

  • Closing request in Manage request does not dismiss the location card. As mentioned in above Testing, we were well aware will this issue, and will apply the patches post-milestone 3.

  • Several colours in the UI might not be constrasted enough for people of sight impairment. This is a very good suggestion, and we will employ a contrast ratio calculation method to ensure every UI components are properly coloured and constrasted to support the vast majority of users.

  • Tapping on My location button on map does not request for permission and never resolves. This is a new discovery, as the opposite occurred during development. We will continue to investigate this issue. Most likely this is an issue with the Google Maps SDK integration.

  • I did not receive any notifications. Upon further inspection, the push notification token for each user was not properly updated in our database. We will continue to investigate this issue.

  • App crashed when there are no requests. This is a recently new development. We will continue to investigate this issue.

  • Tapping on the top half of the New Request button does not trigger the button. This is a recently new development. We will continue to investigate this issue.

  • The keyboard is not dismissed when tapping on some UI components. We found that this issue prevailed on Donate screen. This issue has been fixed, and we will continue to do testing on other UI components to ensure seamless user interaction when the keyboard is open.

Note on compilables

While it is our desire to deliver compilables for users to try BloodConnect, we cannot release the compiled application packages (i.e. APKs for Android and IPAs for iOS). This is due to the fact that we used many APIs, many of which are free with limits, or borrowed API keys. We cannot risk API overuse on our end, so, if you would like to try BloodConnect, we kindly invite you to self-build it by following the instructions here.

important

For Dr Zhao Jin, any Orbital advisors or mentors, if you are interested in testing BloodConnect, please drop me an email at phillmont@u.nus.edu and I will check if my current testing API plan can accomodate. I will be very humbled if you would like to try BloodConnect out :)

Motivation

For a country of approximately 5.7 million people, the 75,655 donors in 2019—approx. 1.33%—was particularly low.1 In fact, in 2019, the Singapore Red Cross and Health Sciences Authority appealed for blood donors as stocks in blood banks reached low levels.2 Approximately 3,000 donors of any types were needed to restore the stocks to a healthy level. This shortage was grave as the blood group with the greatest extent of shortage was O, the universal group used in emergencies, particulary when the blood identity of the patient was unknown. The situation is exacerbated by the fact that the number of young donors is declining at a steady rate, from about 23,000 in 2008 to 18,000 in 2019.1,3 As the population is being increasingly dominated by senior citizens, and the current COVID-19 pandemic progresses, blood donors are needed more than ever.

When there is a lack of supply for a particular blood type in blood banks or hospital inventories, patients and families turn to social media to look for blood donors. While this method may reach a myriad of potential donors, it is not always deterministic. There is also no guarantee that the potential donors are reachable, and this weakness in this method may be crucial in times of crisis. The Singapore Red Cross and HSA have a database of blood donors which are contactable when blood supplies are needed. However, this system limits the coverage to only the regular registered donors. Hence, we propose the development of a platform, BloodConnect, to connect blood donors and donees whenever, wherever. BloodConnect allows users to create blood requests, which are viewable by other users as potential donors. Nearby users will also be notified. If a user decides to donate to a request, they will be connected to the requester and arrange a meeting at the hospital of request. Through this platform, we aim to bridge the gap between donors and donees and decrease the waiting time to find blood, particularly in emergencies.

Aim of project

To ensure consistent healthy supply of blood at bloodbanks and bridge the gap between blood donors and blood seekers, we aim to develop a platform to provide information on blood requests and notify nearby potential donors to reduce the waiting time for blood donations in emergency situations and encourage young donors through a relevant, digital platform with the ease to search avenues for blood donations.

User stories

  • As a blood donor, I want to be able to see blood requests to which I can donate my blood.
  • As a blood donor, I want to be notified when blood donation is required near my location.
  • As a blood seeker, I want to be able to create a blood request with my contact details and connect with an eligible donor fast.
  • As a blood bank administrator, I want to be able to create a blood request when the blood stocks are running low.
  • As a hospital or health institution staff, I want to be able to create a blood request when blood stocks are running low or my patients requires direct blood transfusion.
  • As a research institution staff, I want to be able to create a blood request when I need donors for research purposes (e.g. recovered COVID-19 donors for vaccine research, etc).
  • As an blood donation event organiser, I want to be able to create a blood request inform of my event and increase participation.

Scope of project

The platform utilises mobile (for Android and iOS) and web applications as the front-end interfaces for blood donors to view and respond to blood requests and blood seekers to create blood requests. The mobile app is being developed with React Native and the web app will be developed with React.

A set of back-end APIs will be developed for authentication, database, push notifications, and pairing algorithms. This will be developed with Node.js and Firebase cloud functions.

Mobile application

This app is the main BloodConnect app which enables users to create, view, and respond to blood requests. Registered users will be able to view their donations/requests history and be notified of nearby blood donations. Users can also share blood requests to their friends.

Smart search

The search function in BloodConnect will be developed to allow searches based on blood type, types of venues, emergency, time, descriptions, and venue names. In addition, voice search will also be implemented.

Maps

BloodConnect will make use of the Google Maps API (for Android) and Apple Maps (for iOS). The blood requests will appear on the map and users will be able to tap on the markers to see the details for each requests.

Authentication

Using Firebase, BloodConnect allows for user accounts creation. In addition, OAuth will also be implemented to allow users to create account with existing services, e.g. Google or Facebook accounts.

Push notifications

Nearby donors (registered users) will be notified when a blood request is made requiring their blood type. Users can opt to be notified of all blood requests, only emergency ones, those coming from specific venues (hospitals or blood banks), etc.

Other platforms

We did a literature review and there have been similar platforms developed, such as Simply Blood, Donor2Donor, Blood4Life.ID, and Red Cross Connection.

  • Simply Blood, developed in 2017
    Simply Blood is an Android and web app developed as a platform to connect blood donors with blood seekers to alleviate blood shortage, wastage, and transfusion waiting time. After inspecting the app, we saw that it requires all users (donors and seekers) to create an account with their mobile phone number, which is verified by an SMS OTP. The app also requires blood requesters to provide their full name, which may be considered a privacy concern, as some users may not want to disclose the fact that they have medical conditions which require blood transfusion. With BloodConnect, we will design a more intuitive UI which not only looks modern and recent, but also easy to use. BloodConnect will only require blood seekers to register and verify their email address to prevent illegal activities, but allow blood donors to use the app without registration. However, blood donors can create an account to view their donation history, save their fitness survey for a set period of time (TBC), and be notified of any nearby blood requests. BloodConnect will not require users' full name for privacy reasons.

  • Donor2Donor, developed in 2016
    This app takes a different approach towards finding blood donations. First of all, this app also allows for organ donations, not only blood donations. Secondly, this app allows blood seekers to find available blood donors with maximum radius of 50 km. This approach is different from BloodConnect's, as donors will have to publish their availability in the platform and blood seekers will choose from a list of available donors. Donor2Donor, despite having their website written in English, seems to focus on the Indian community, as their ads are mainly in Hindi. We aim to enable connections in any parts of the world.

  • Blood4Life.ID, developed in 2009
    In 2009, Blood4Life.ID used mailing lists, and shifted to Twitter and Facebook in 2010. In 2019, they developed the web application as a more systematic platform. It appears that Blood4Life.ID takes a more social approach, as their web app contains a lot of posts, events, news, community collaterals, and blood requests map in between. Also, this platform is only available for the Indonesian community. Its blood donation search function only "posts" request and donors will have to search and contact the requester directly. With BloodConnect, it will notify nearby users and there is a call-to-action for donors to connect with the requester.

  • Red Cross Connection, developed in 2014
    This platform was developed by the Singapore Red Cross as a campaign, and was officially announced in January 2014.4 It shared similarities with BloodConnect, however, it is no longer operational. The app allows users to post the "number of lives they have saved" and view the "number of blood donations made by their peers".5 We believe that this feature does not value-add into the problem that the platform was aiming to tackle: amplifying the search for donors.4 Instead, this feature may make blood donation seemed competitive and users can showcase the "number of lives they have saved". As a reward, blood donors may scan a QR code at donation sites to view an AR animation an an appreciation for their "selfless and heroic acts".6 While we agree with the campaign's message that donating blood is a heroic act, the aim of BloodConnect's development is not as a campaign, but as a tool to solve the problem with finding blood. That being said, as of now, we do not plan to take a gamified approach towards blood donation.

Program flow

Program and user flow diagram

Progress video

If you cannot view the video in the frame below, click here to watch it on YouTube.

Project poster

Click here to view the poster.

Project log

NoTaskDatePhillmont (hours)Ivan (hours)Remarks
1Milestone 2 peer reviewJun 88
2Meetings with Gerald and Leslie on Milestone 2Jul 1, 533Discussed about what to expect for Milestone 3, UI and layout improvements, feedback on user flow, and guides for developing a comprehensive user testing.
3Applying bugfixes from Milestone 2Jul 6-1230See the fixes promised in Milestone 2 here.
4Upgrading code baseJul 1410Upgraded to Expo SDK 38 and React Native 0.62, deprecated and vulnerable packages, and resolved breaking changes.
5Refactoring UI componentsJul 1520Designed a new (but ultimately rejected) Button component, combined several components, removed redundant components, fixed Touchable responsiveness issues with SDK 38, etc.
6Restructuring realtime database synchronisation and auth persistenceJul 16-1740Difficult due to Expo's compatibility issues with native Firebase, so use only Firebase JS. Fixed event listeners unsubscription (infinite async calls), migrate local storage to AsyncStorage, fixed Firebase authentication persistence to allow storing authentication state, etc.
7Developed Smart searchJul 1810
8User testing: Phase 1Jul 20-2325
9Applying user feedback from Phase 1Jul 2510
Total hours14811

Total hours spent by both Orbitees: 148 + 11 = 159 hours.