No Text

The application has no text. This was an intentional design choice.

Every element (navigation, lessons, feedback) is accessed through symbols and sound. A user who cannot read a single character can open the app, find a lesson, and begin learning. In our trials, we found this minimised the burden on the learner and removed the barrier that defeats most literacy apps before they begin.

Local Deployment

Our approach runs on the minimum possible hardware. The application downloads and runs on the lowest-cost Android devices available.

The model is lightweight and processes locally. There is no server dependency, no constant data cost, no need for stable infrastructure. A user connects to WiFi once to install the app and download content. From there, learning happens offline.

This matters because the people we are building for do not have reliable internet. They cannot stream lessons. They cannot make API calls. The solution must work where they are, not where connectivity is easy.

Adaptive Difficulty

The app monitors how a learner interacts with content: rereads, replays, time spent, response patterns.

This is based on Krashen's input hypothesis: the idea that language is acquired when input is comprehensible and just slightly above the learner's current level. Krashen calls this i+1. Too easy, and there is no learning. Too hard, and there is no comprehension.

A locally deployed model uses these metrics to adjust difficulty in real time. Content stays at i+1 without requiring manual calibration or teacher intervention.

Interest-Based Personalisation

The same metrics that track difficulty also reveal interest.

If a learner replays content about animals more than content about vehicles, the app registers that. A lightweight model builds an interest profile over time. The app then pulls more English content around those themes: sports, science, stories, whatever engages them.

When learners are interested, they stay engaged. When they are engaged, they learn faster. This is not a new insight, but it is rarely implemented for this population because it requires local processing that most apps do not support.