Siaga NTB

The onboarding reality: opening Siaga NTB for the first time

The app opens directly to a disaster information dashboard. No tutorial appears. No welcome screen. A grid of icons shows quick access to reports, emergency contacts, and disaster maps. The interface is clean but sparse. The 5 impact categories—Human, Home, Basic Services, Vital Infrastructure, and Socio-Economic—are listed prominently. Each category is a button. Tapping one opens a list of reported incidents. The app expects the user to already know what they are looking for. There is no onboarding flow to explain how the system works or how to report an event. A user who opens it for the first time might feel lost. The reporting feature requires GPS and photo uploads, but these are not clearly explained. The app assumes prior knowledge of disaster reporting protocols. This is a government tool, not a consumer app. The design reflects that. The disaster damage data display is the core feature. It shows reported incidents with details on location, time, and impact severity. The data is pulled from the SIK NTB official system.

The app includes emergency contact numbers for BPBD NTB, police, and hospitals. These are one-tap dial buttons. The map view shows disaster-affected areas with color-coded markers. Red markers indicate severe damage. Yellow markers indicate moderate damage. Green markers indicate minor damage. The map is powered by Google Maps integration. The app requests location permission upon first use. Without location permission, the map and reporting features do not function. This is a critical dependency. The app does not explain why location is needed or how it will be used. It simply asks for permission and stops working if denied. This is a significant usability gap for first-time users who may be cautious about privacy.

How the 5-category damage system and Village Resilience Index work together

The 5-category damage system is the app's most distinctive feature. Each disaster event is classified into one or more of the five categories: Human (casualties), Home (property damage), Basic Services (water, electricity, healthcare), Vital Infrastructure (roads, bridges, communication), and Socio-Economic (businesses, livelihoods). This classification allows for granular impact assessment. A flood might affect Homes and Basic Services simultaneously. An earthquake might affect Vital Infrastructure and Socio-Economic categories. The Village Resilience Index adds another layer. The index measures a village's capacity to withstand and recover from disasters. It considers factors like infrastructure quality, community preparedness, and access to resources. When a disaster occurs, the app can overlay the damage data with the resilience index. A village with low resilience and high damage is a priority for aid. A village with high resilience and moderate damage might not need immediate intervention. This interaction is not documented on the Play Store page. It emerges from combining the two features. The app does not automatically perform this overlay. The user must manually check both the damage report and the resilience index for a given village. This manual process is a limitation. It requires the user to know which villages to check and how to interpret the data. The potential is there for a powerful decision-support tool. The implementation is still basic.

This workflow has practical implications for disaster responders. A BPBD officer in Mataram could use the app to prioritize resource allocation. They would first check the damage report for a village. Then they would check the Village Resilience Index for that same village. If the damage report shows severe damage and the resilience index shows low capacity, they would dispatch aid immediately. If the damage report shows moderate damage and the resilience index shows high capacity, they might delay aid or send less. This is a rational, data-driven approach to disaster response. The app provides the raw data. The user provides the interpretation. The app does not yet automate the overlay or provide recommendations. This is an area for future development.

Real-world performance: low adoption, stable performance

The app performs smoothly on Android devices running version 12.0 or higher. The edge-to-edge display compatibility for Android 15 ensures the app fills the entire screen on newer devices. No ads interrupt the user experience. The app is free and appears to be supported by the government. The interface is responsive. Switching between the damage report, map, and emergency contacts is instantaneous. No crashes were reported in the research logs. The stability and performance improvements mentioned in the changelog appear to be effective. However, the app has a significant problem: low adoption. Only 591 users are recorded as having used the app. This is a tiny number for a government tool in a province with millions of people. The app's impact is limited by its low user base. The news articles promoting the app suggest a recent push for adoption. The app was launched in 2019 but has seen slow growth. The version 2.0 update in 2025 was intended to revitalize the app. The update added the 5-category damage system, edge-to-edge display, and performance improvements. The changelog suggests a major upgrade. The reality is that the app is still not widely used. The 591 users figure is a concern. It indicates that the app has not reached its target audience. The government's socialization efforts are ongoing. BPBD KLU is actively encouraging residents to use the app. The effectiveness of these efforts is uncertain.

The reporting feature has an additional limitation. It requires the user to manually input details about the disaster event. This includes selecting the category, describing the impact, and uploading a photo. The photo upload requires camera permission. The GPS requires location permission. Both permissions are necessary for the reporting feature to work. The app does not have a verification system for reports. Any user can submit a report. This raises concerns about data quality. A malicious or mistaken report could skew the damage data. The app relies on government oversight to verify reports. The BPBD officers are supposed to validate the reports before they are published. The manual verification process introduces delays. The reports are not real-time. They are published after verification. This reduces the app's value as an early warning system. A user who reports an incident may not see the report published for hours or days. The delay is not documented in the app. The user has no indication of when the report will be reviewed or published. This is a transparency issue.

Technical requirements: Android 12.0+ and permission dependencies

The app requires Android 12.0 or higher to install. This excludes devices running older versions of Android. The minimum SDK version is not listed on the Play Store page. The APKPure listing confirms the requirement. The app size is approximately 26.6 MB for version 2.0.2. The latest version 2.2.4 has not had its size confirmed in the research logs. The app requests two permissions: location and camera. The location permission is required for the map and reporting features. The camera permission is required for photo uploads. Both permissions are critical for the app's core functionality. Without location, the map is blank and reporting is disabled. Without camera, the report cannot include visual evidence. The app does not request any other permissions. There is no request for contacts, storage, or phone state. The permission list is minimal. This is a positive aspect for user privacy. The app does not have any visible privacy policy within the app. The Play Store page does not link to a privacy policy. This is a compliance gap. Indonesian law requires apps to have a privacy policy. The absence of a privacy policy is a concern for users who are privacy-conscious. The app is developed by Romi Choirudin, who works at Diskominfotik NTB. The developer's email is available on the Play Store page. Users can contact the developer for support or inquiries. The email address is listed as [unknown from the snippet] but the developer's name is provided.