Home‎ > ‎HOW - Technology‎ > ‎Announcements‎ > ‎

Suggested High Level architecture

It recognises two distinct domains:
1. The mobile app
2. What you need back home at HQ

The mobile app:

- Would need to be a native app in order to package content
- Seeing as a single tablet will likely go to lots of kids, a key
requirement is for the kids to identify themselves (and there ought to be
incentives for doing so) otherwise, you can only track usage and
progression data at device level. In other words, you¹d need to think
about the data you want to generate and design the solution in line with
- In order for you to be able to generate xAPI data and capture this on
the device (which will likely be offline most of the time), any learning
content would need to be packaged within the app. I.e. I don¹t think it¹s
possible for one app to generate data for another app on the device
without an internet connection.
- I therefore propose that any content would need to be developed as HTML
packages (pretty much the regular scenario for e-learning packages) and
delivered via an embedded browser (which is straight forward to achieve).
- this likely means that you will want a content creation framework so
that you have a degree of consistency and can develop content
cost-effectively. A consistent interface is also likely to make the
learning easier as the kids will get used to the standard interface. This
is where a project like Adapt can help: https://community.adaptlearning.org
- the app would have to have a content catalogue - I.e. A selection
mechanism for which content to launch. Given that the kids may not be
computer literate, an icon-based, graphical interface may well be the best
approach. The icons would need to be considered in the cultural context -
e.g. How best to express a subject like Œmaths¹ etc.
- the app would essentially work in the same way as some elearning
Œoffline players¹, I.e. They carry the content on the local device, can
launch it within a browser and Œfake¹ an API, which the elearning talks to
and sends tracking statements to (this is what is meant by ŒxAPI
connector¹ in the diagram. There would also need to be a database / data
store for the statements attached to the app.
- while the devices are expected to be offline, I still think it¹s worth
building in the ability to configure, sync and download data remotely if
there is an internet connection. Presumably, it is easier to get the
device to a place where there is connectivity take connectivity to the
devices (e.g. Via satellite phone) in some circumstances (even if not all
the time) - this is a Œjust in case¹ thought. For this reason, I have also
included the content sync and data uploader components in the concept.

Systems at HQ:
- there would need to be an LRS into which all the data can be poured. A
key question here is the level of granularity to which the data attaches -
I.e. Is it Œone record set for the whole project¹, one record set for each
device or one record set for each identifiable user.
- there is an open source LRS called Learning Locker, which may help:
- this has a built in web frontend for admins, which does some basic
analysis or at least data visualisation
- to this master data record, you could attach analytics software and
create reports. Some of these you may wish to make publicly available
- there would also need to be a data uploader service (whether this is a
web service, which you can call remotely or a script, which allows you to
import data copied directly from the device)
- over and above this, I think you could think of how to enable partners
to create content for the project - so a content creation tool and a
shared content catalogue might be worth considering.

I hope this makes some sense - I know it has been a while since we talked.
Please feel free to ask any questions you may have.

All the best,