Designing early-warning apps for low bandwidth
Why a warning app has to work on a weak connection, and the design rules that keep the message small, fast and readable.
A flood warning is most valuable in the place where the phone signal is weakest: a valley below a cloudburst-prone slope, a village at the end of a mountain road, a riverbank in heavy rain. Yet most apps are built and tested on fast office Wi-Fi. This article explains how to design an early warning app for low bandwidth, so that the few kilobytes that matter get through when the network is poor. The same rules help any of the low bandwidth applications people use in the field.
Why does bandwidth matter for an early warning app?
Bandwidth matters because a warning is only useful if it arrives and can be read before the hazard does. A slow or failing load turns a ten-second check into a minute of staring at a spinner, and people stop trusting the app.
Connectivity is also uneven. The GSMA's 2025 report estimates that 3.4 billion people were not using mobile internet in 2024. Of these, about 300 million (4 % of the world's population) live outside mobile broadband coverage, while 3.1 billion (38 %) live within coverage but do not use it. Barriers include handset affordability, digital skills and relevant content [1]. For a warning designer this means two things. Some users have no signal at the moment of danger, and many others have a signal that is slow, intermittent or paid for by the megabyte.
Hills add their own problems. Signal drops in narrow valleys and during storms, which is when alerts matter most; see river monitoring in hill and Himalayan catchments.
What makes an app work on a slow connection?
An app works on a slow connection when it asks the network for as little as possible, asks for the most important thing first, and keeps working when the network does not answer. The W3C's Mobile Web Best Practices make the same point for web content: keep the number of external resources to a minimum, because each one needs a separate network request, and limit content to what the user has requested [2]. The document dates from 2008, but the physics of a slow link has not changed.
Put the message first and keep it small
Text is far cheaper than pictures. The W3C advises avoiding large or high-resolution images "except where critical information would otherwise be lost", keeping style sheets small and using terse markup [2]. For a warning screen this suggests a simple order of loading: first the alert text (what, where, how severe, what to do), then the latest reading, and only then maps, charts and photographs.
The Common Alerting Protocol (CAP), the international message format for alerts, is built the same way. Each message is a structured text document with an event description, the area it applies to, and urgency, severity and certainty fields. Its headline field exists because "some displays (for example, short messaging service devices) may only present this headline" [3]. A good alert reads correctly even if only the headline arrives. For wording, see writing warning messages people act on.
Reduce round trips
On a slow, high-delay link, ten small requests cost more than one slightly larger one. The W3C advises balancing the number of links per page against the number of page retrievals, avoiding automatic redirects and limiting external files [2]. In an app this means fetching the dashboard data in one request, not one per station, and avoiding chains where one response must arrive before the next can be asked for.
Cache, and say how old the data is
The W3C recommends giving caching information in server responses [2], so that a phone does not download again what it already holds. The app should keep the last good reading on the device and show it with its time: "Water level 2.31 m, 14 minutes ago". A stale value with an honest timestamp is far better than a blank screen. A value shown without its age can be dangerously misleading during a fast rise.
Fail gracefully
The same W3C document tells designers not to rely on scripting, cookies or styling being available, and to give a text equivalent for non-text content [2]. For a warning app, the modern equivalent is that a failed map tile, a missing font or a timed-out chart must never hide the alert. Show what you have, mark what is missing, and retry quietly in the background.
A worked example: how long does a screen take to load?
The table below is illustrative. It takes an effective link speed of 64 kbit/s, a poor but realistic figure on a weak 2G-like connection, and divides the data size by the speed. It ignores connection set-up and delay, so real times would be longer.
| Item | Size | Bits | Time at 64 kbit/s |
|---|---|---|---|
| Heavy screen: large images and scripts | 2 MB | 16,000,000 | 16,000,000 / 64,000 = 250 s (about 4 minutes) |
| Lean screen: text, small icons | 20 kB | 160,000 | 160,000 / 64,000 = 2.5 s |
| Alert text only | 1 kB | 8,000 | 8,000 / 64,000 = 0.125 s |
The point is the ratio, not the numbers. The alert text is a thousand times lighter than the heavy screen, so it can still arrive when the heavy screen would have timed out. The first screen should therefore be the lean one, with the heavy content fetched only on request.
Beyond the app: do not depend on it alone
Even a lean app needs a data connection and a charged phone. A warning chain should therefore also use channels that work without a data plan, such as SMS and sirens, and the app should be one layer among several. That is the design logic of early warning dissemination through sirens, SMS and CAP. On the sending side, low bandwidth also shapes the field stations, whose links are chosen for reliability over speed; see telemetry link design for hydromet stations.
A checklist for designers
- Test on a throttled, high-latency connection and on a mid-range handset, not only on office Wi-Fi.
- Show the alert text and its time first; load everything else afterwards.
- Count requests and kilobytes for the first screen and set a budget for both.
- Keep the last good data on the device and show its age.
- Make every image, map and chart optional, never required to understand the warning.
- Use plain, short messages in the languages people actually read.
Key points
- A warning is only as good as its delivery, and delivery is often over a weak, slow or costly connection.
- Millions of people live within mobile coverage yet do not use mobile internet, so connectivity at the point of need cannot be assumed [1].
- Send text first, keep requests few, cache sensibly and always show how old the data is [2][3].
- A failed map or chart must never hide the alert.
- An app should be one channel among several, alongside SMS and sirens.
Where ClimMaTech fits
Aagah is the ClimMaTech mobile app for flood forecasts, weather forecasts and early warnings on a phone. It has four simple tabs (Dashboard, Weather, Alerts and Settings), and where ClimMaTech hardware is installed near you it also delivers early warnings. Learn more on the Aagah page.
References
- GSMA, The State of Mobile Internet Connectivity 2025 (press release "GSMA calls for renewed focus on closing the usage gap as more than 3 billion people remain offline despite available mobile internet services", 9 September 2025). gsma.com
- J. Rabin, C. McCathieNevile (editors), Mobile Web Best Practices 1.0, W3C Recommendation, 29 July 2008. w3.org
- OASIS, Common Alerting Protocol Version 1.2, OASIS Standard, 2010. docs.oasis-open.org