...

Java Spring Boot is an ideal choice for the backend of the GovStack architecture due to its ease of use, scalability, and strong community support. Its capabilities align well with the goals of the initiative, enabling the development of efficient, secure, and maintainable digital government services that can adapt to evolving needs.

...

Technical Documentation

...

GitHub repositories

Git

The repositories can be accessed here:

...

...

...

...

Database Schema

Threat Table

Broadcast Table

...

How to up and run the demo locally

Prerequisites: node and yarn and docker

Backend services

(for each service)

1. up and run docker

2. create a new network in Docker using the command docker network create shared_network

3. up and run Information mediator using the docker file

4. clone/Download each service in a new folder (if downloaded, unzip the folder)

5. start each service by opening the service folder in a new terminal

6. run the command docker-compose up --build

Frontend

1. once backend services are running, clone the frontend repository

2. open a terminal and open on it the root folder of the frontend repository

3. copy the .env.example  to .env. This can be done with this command:

   • cp .env.example .env

4. verify that the values in .env are correct. They will be if they haven't modified anything while starting the microservices.

5. next step is to install the frontend dependencies. this can be done, again with the terminal and again in the root folder, by executing this command: yarn install

6. after all of this, they are ready to start the project. to do that they can, again in root folder and with the terminal, run this command: yarn dev

7. once they have ran that command, they can open their browser and open the url http://localhost:3000/

8. this will open the login page, default credentials are:

   • user: firstUser@test.com

   • password: asdf1234

Something similar is mentioned in frontend's readme: https://github.com/GovStackWorkingGroup/sandbox-usecase-earlywarning-frontend/blob/main/README.md

Port mapping

Database Schema

Threat Table

County Country Table

Broadcast Table

Flow & Key Functionalities

This section outlines the core user flows and key functional capabilities of the Husika early warning system, as envisioned in the Figma design mockups.

The system is designed to support three primary user flows:

1. Threat Monitoring

2. Broadcasting

3. Feedback Collection

These flows are supported by a set of integrated features and an information architecture that enables users to effectively manage threats, communicate with stakeholders, and collect valuable feedback.

Figma Documentation:

...

Core User Flows

The three core user flows are described in detail below, based on the Figma designs:

Threat Monitoring

Design:

• The Threat Monitoring functionality is accessible from multiple entry points in the system:

  • The Dashboard provides an overview of active and high-priority threats, which users can click through to access the full Threats view.

  • The Threats page serves as the central hub for monitoring and managing threats, offering a comprehensive tabular listing.

• On the Threats page, users can view all threats across their jurisdiction but also other areas too, Users can see:

  • The threats list based on criteria such as threat status, location, severity, and more.

  • Quickly identify high-priority threats through visual cues like color-coded severity indicators.

• The threats table includes the location information for each threat, displayed with an icon to indicate whether the threat is within the user's jurisdiction or outside of it.

• Clicking on a specific threat in the Threats list opens the Threat Details view, which includes:

  • A map-based visualization showing the geographic location of the threat.

  • A timeline of events and associated metadata for the threat.

  • The ability for users to submit structured feedback to the ICPAC (IGAD Climate Prediction and Applications Centre) through a dedicated feedback form.

Example Flow/Visualization:

...

Implementation Notes:

Broadcasting

Design:

• The Broadcasting flow enables users to create and send alerts to their stakeholders such as citizens or organizations.

• The broadcast creation process is divided into three steps:

  1. Configuration: Users select the communication channels (email, SMS, WhatsApp, Telegram), target languages, and recipients.

     1. Recipients can be Whole population within Jurisdiction

     2. Organizations within Jurisdiction

     3. Or custom recipients, such as certain user group that is created beforehand. (pastoralist within certain area)

  2. Content Creation: Users craft the broadcast message, optionally select a pre-made template, and configure response options (validation, general feedback or none).

  3. Preview & Review: Users review the broadcast details, estimated reach, and content preview before finalizing and sending the broadcast.

• The broadcast creation interface supports multi-language editing and file attachments.

• Users can track the status of their broadcasts (draft, processing, sent, failed) in the Broadcasts page.

Example Flow/Visualization:

...

Implementation Notes:

Country Threat Table

County Country Table

Flow & Key Functionalities

This section outlines the core user flows and key functional capabilities of the Husika early warning system, as envisioned in the Figma design mockups.

The system is designed to support three primary user flows:

1. Threat Monitoring

2. Broadcasting

3. Feedback Collection

These flows are supported by a set of integrated features and an information architecture that enables users to effectively manage threats, communicate with stakeholders, and collect valuable feedback.

Figma Documentation:

...

Core User Flows

The three core user flows are described in detail below, based on the Figma designs:

Threat Monitoring

Design:

• The Threat Monitoring functionality is accessible from multiple entry points in the system:

  • The Dashboard provides an overview of active and high-priority threats, which users can click through to access the full Threats view.

  • The Threats page serves as the central hub for monitoring and managing threats, offering a comprehensive tabular listing.

• On the Threats page, users can view all threats across their jurisdiction but also other areas too, Users can see:

  • The threats list based on criteria such as threat status, location, severity, and more.

  • Quickly identify high-priority threats through visual cues like color-coded severity indicators.

• The threats table includes the location information for each threat, displayed with an icon to indicate whether the threat is within the user's jurisdiction or outside of it.

• Clicking on a specific threat in the Threats list opens the Threat Details view, which includes:

  • A map-based visualization showing the geographic location of the threat.

  • A timeline of events and associated metadata for the threat.

  • The ability for users to submit structured feedback to the ICPAC (IGAD Climate Prediction and Applications Centre) through a dedicated feedback form.

Example Flow/Visualization:

...

Implementation Notes:

• For the prototype, the Threat Monitoring functionality is limited to only the Kenya jurisdiction.

• The "See other affected Locations" section on the Threat Details page is not implemented in the current prototype.

• The map visualization on the Threat Details page is a placeholder and does not reflect the actual geographic location of the threat. The map functionality is not implemented in the prototype.

Broadcasting

Design:

• The Broadcasting flow enables users to create and send alerts to their stakeholders such as citizens or organizations.

• The broadcast creation process is divided into three steps:

  1. Configuration: Users select the communication channels (email, SMS, WhatsApp, Telegram), target languages, and recipients.

     1. Recipients can be Whole population within Jurisdiction

     2. Organizations within Jurisdiction

     3. Or custom recipients, such as certain user group that is created beforehand. (pastoralist within certain area)

  2. Content Creation: Users craft the broadcast message, optionally select a pre-made template, and configure response options (validation, general feedback or none).

  3. Preview & Review: Users review the broadcast details, estimated reach, and content preview before finalizing and sending the broadcast.

• The broadcast creation interface supports multi-language editing and file attachments.

• Users can track the status of their broadcasts (draft, processing, sent, failed) in the Broadcasts page.

Example Flow/Visualization:

...

Implementation Notes:

• For the prototype, only the SMS channel is implemented for broadcasting. Other communication channels like email, WhatsApp, and Telegram are not available.

• The prototype supports only two languages for broadcast content: English and Swahili. Additional language options are not implemented.

• The prototype limits the broadcast recipients to only the population within the user's jurisdiction. Functionality for selecting custom recipient groups or organizations is not implemented.

• The broadcast creation process includes the "Validate Status" response option, but the "Estimated reach" section is a placeholder and does not display actual reach estimates.

• The template-based broadcast creation functionality described in the design is not implemented in the prototype.

• Within the Quick Action, Create Broadcast button on the Dashboard and broadcasts page does not actually initiate the broadcast creation flow.

• The success dialog or confirmation screen after sending a broadcast is not implemented in the current prototype.

Feedback Collection

Design:

...

Broadcast Feedbacks:

...

Implementation Notes:

...

• The feedback collection functionality described in the design is not implemented at all in the current prototype. Users are unable to submit feedback to ICPAC regarding threats or provide feedback on broadcasts through Rapidpro.

Key Features

Dashboard

Design:

• The Dashboard provides users with a high-level overview of the key metrics and activities within the early warning system.

• The dashboard includes the following sections:

  • Threats: Displays the number of active threats and high-priority threats across the user's jurisdiction.

  • Broadcasts: Shows the number of

  the key metrics and activities within the early warning system.

• The dashboard includes the following sections:

  • Threats: Displays the number of active threats and high-priority threats across the user's jurisdiction.

  • Broadcasts: Shows the number of broadcasts that have been sent and are currently pending.

  • Feedbacks: Indicates the total number of received feedbacks and the number of feedbacks received today.

• Each of these overview sections can be clicked to navigate to the corresponding detailed view (Threats, Broadcasts, Feedbacks).

• The Dashboard also includes a "Recent Threats" section, which lists the most recent threats within the user's jurisdiction. This section provides a quick snapshot of the current threat landscape.

• Users can easily access key actions from the Dashboard, such as creating a new broadcast.

Visualization:

...

Implementation Notes:

• • broadcasts that have been sent and are currently pending.

  • Feedbacks: Indicates the total number of received feedbacks and the number of feedbacks received today.

• Each of these overview sections can be clicked to navigate to the corresponding detailed view (Threats, Broadcasts, Feedbacks).

• The Dashboard also includes a "Recent Threats" section, which lists the most recent threats within the user's jurisdiction. This section provides a quick snapshot of the current threat landscape.

• Users can easily access key actions from the Dashboard, such as creating a new broadcast.

Visualization:

...

Implementation Notes:

• The "Latest Broadcasts" section on the Dashboard is not clickable in the current prototype. Users cannot navigate to the Broadcasts page from this section.

• The "Quick Actions/New Broadcast" button on the Dashboard does not initiate the broadcast creation flow as described in the design. This functionality is not implemented in the prototype.

• The banner numbers displayed on the sidebar (for Threats, Broadcasts, and Feedbacks) are placeholder values and do not reflect the actual real-time data in the system.

Threat Details

Design:

• The Threat Details page provides a comprehensive view of a specific threat, accessible by clicking on a threat from the Threats list.

• The page includes the following key elements:

  • Location: A map visualization showing the geographic area affected by the threat, with clear indication of the user's jurisdiction.

  • Threat Details: Detailed information about the threat, including type, severity, period, and associated metadata.

  • History Timeline: A chronological timeline of events related to the threat, from when it was first created to its current status.

  • ICPAC Feedback: A dedicated section where users can submit structured feedback to the IGAD Climate Prediction and Applications Centre (ICPAC) regarding the threat.

  • History Timeline: A chronological timeline of events related to the threat, from when it was first created to its current status.

  • ICPAC Feedback: A dedicated section where users can submit structured feedback to the IGAD Climate Prediction and Applications Centre (ICPAC) regarding the threat.

• Broadcast List: A table displaying all broadcasts that have been created in relation to the selected threat. This includes:

  • Title of the broadcast

  • Language of the broadcast content

  • Communication channel used (e.g., Telegram)

  • Date the broadcast was sent

  • Status indicators (e.g., Sent, Processing)

• Users can easily navigate back to the Threats list or access other core functionalities like creating a new broadcast from the Threat Details page.

• The page layout and design provide a clear, comprehensive view of the threat and associated broadcasts to support effective monitoring and response.

Visualization:

...

Implementation Notes:

• Broadcast List: A table displaying all broadcasts that have been created in relation to the selected threat. This includes:

  • Title of the broadcast

  • Language of the broadcast content

  • Communication channel used (e.g., Telegram)

  • Date the broadcast was sent

  • Status indicators (e.g., Sent, Processing)

• Users can easily navigate back to the Threats list or access other core functionalities like creating a new broadcast from the Threat Details page.

• The page layout and design provide a clear, comprehensive view of the threat and associated broadcasts to support effective monitoring and response.

Visualization:

...

Implementation Notes:

• The Threat History timeline displayed on the Threat Details page is a placeholder and does not reflect the actual chronological events related to the threat.

• The "Other Affected Locations" section, which was mentioned in the design, is not implemented in the current prototype.

• The map visualization on the Threat Details page is a placeholder and does not show the actual geographic location of the threat. The map functionality is not fully implemented.

Broadcast Creation

Design:

...

Implementation Notes:

• Please check: https://govstack-global.atlassian.net/wiki/spaces/DEMO/pages/919764994/Husika+Hando-over+documentation#BroadcastingBroadcasting/implementation notes section.

...

Feedbacks

Design:

• The system provides comprehensive feedback management capabilities, supporting two distinct feedback channels:

...

• The robust feedback management capabilities are accessible from multiple entry points in the system, including the dedicated Feedback page and the Broadcast Details page.

• These comprehensive feedback mechanisms enable users to thoroughly understand the impact and effectiveness of their communication efforts for both threats and broadcasts, allowing them to continuously improve their emergency response strategy.

Implementation Notes:

Please check https://govstack-global.atlassian.net/wiki/spaces/DEMO/pages/919764994/Husika+Hando-over+documentation#Feedback-Collection Feedback collection- Implementation notes section.

Lessons Learned

Starting with clear documentation and importance of user research etc.

...