Note: Slides for this project are now posted to Slideshare at http://www.slideshare.net/sverma/xovis-analyticsvisualizationsugarolpc-3...
Update: Martin Dluhos has published a post at OLENepal's blog site, which was written independent of this post, but acts as a good companion to this post, especially highlighting the ways in which OLENepal can compare data across schools. http://blog.olenepal.org/index.php/archives/902
The "Quest for Data" project has been going on for a while now. You can take a look at previous posts to get an idea, but the short of it is that we've had several efforts to gather data that allows us to peek into the usage behavior of projects. These have happened in Paraguay, Jamaica, Australia, India, Peru and a few other places. XOVis is a newer incarnation in that string of efforts. Thankfully, this one builds on the foundations of some of the previous ones.
Learning Analytics is defined as a process with four phases: measurement, collection, analysis and reporting. In case of Sugar, the measurement happens within each activity - more specifically through its metadata - where we use proxies such as start time, collaboration, type of activity, file produced, etc. to assess a level of engagement. For the purposes of this post, we'll go with the assumption that these proxies imply correlation with engagement, and therefore to learning (yes, this is a big assumption, but this is a blog post, and not a double-blind peer reviewed journal paper, so I won't get into it here).
Visualization is an important stage in the reporting process, although by itself, it may lead to incomplete assessments. Visualization tends to be used with aggregates, that is the aggregate behavior of a classroom , school or a collection of schools. So, for instance, we may be interested in seeing how a group of children use Sugar activities during school hours versus outside of school hours (for those fortunate deployments where the laptop goes home).
The data flow is from the laptop's Journal, to an automated Journal backup set on the School Server (XS or XSCE), to the extraction of metadata, to aggregate analysis and finally visualization. There are several ways to do this, but we chose to look at a three-tier architecture: The laptop's Journal, The School Server and the hypothetical Ministry of Education or NGO central cloud service. Metadata flows from XO to XS[CE] via automated rsync backups. Metadata flows from XS[CE] to the Ministry/NGO central server through a mechanism explained below.
At this point, I must specify that the XOVis application was written by Martin Dluhos, while he was working at OLE Nepal, while I helped with the overall architecture, based on my experiences in Jamaica and India, and Andi Gros helped with the visualization front-end. The work that Martin did is thankfully built on top of what Raúl Gutiérrez Segalés and Leotis Buchanan did earlier in Paraguay and Jamaica respectively. We also involved input from Martin Abente Lahaye about Australia's Harvest system, and Anish Mangal about sugar-stats, and were mindful to create an architecture that can accommodate both systems (these other systems will need some coding labor, of course).
Resuming the explanation, one of the key issues was to deal with the problem of offline and intermittent connectivity to School Servers. We needed a glue that connected the School Server to a central location, and would be resilient to pick up sync where it left off, and do so without human intervention (very much like rsync). Then we would need an engine to aggregate the data across different cross comparisons - averages and comparisons of usage by day, by month, by year, etc. This is where CouchDB magic comes in. CouchDB can:
- Store data as json documents at the School Server.
- Generate aggregates using MapReduce.
- Synchronize from School Server to Ministry-of-Education/NGO over broken/intermittent connections (can also use a USB stick sneakernet).
- Make coffee while running all of the above (ok, so that's not true)
Could we use CouchDB to address all these needs? Yes! So, we used CouchDB to do #1, #2, #3, and #4. For #5, you are on your own :-)
So, this is somewhat how it goes. You can head over to GitHub (https://github.com/martasd/xovis) and grab the code. If using a XS (I haven't tested yet) I'd recommend that you install by hand, using the
script. If you are running your project on XSCE, use the ansible playbook for xovis.
will play all playbooks and install all services, including xovis. To install xovis only, do
ansible-playbook -i ansible_hosts xsce.yml --connection=local --tags="xovis"
Next, make sure that you have Journal backups in
If you have registered XOs with this School Server, the backups will start to happen automatically (takes 30 minutes or so). If you have user backups, then you can run the process_journal_stats.py script to do a bunch of things.
will export metadata to comma-separated value (csv) format for analysis in Excel, LibreOffice or R.
will spit out stats for activities
process_journal_stats.py dbinsert xovis --deployment <deployment-name> --server http://admin:email@example.com:5984
will push the metadata into the local CouchDB database on the School Server. Note that the admin:admin userid:password may/should change.
Next, to visualize what your deployment has been up to, open up a browser on a machine connected to your School Server. Go to
Pick your deployment from the dropdown and click on a button to check out the visualization!
Frequency of use
Activities by month
Activities by time of day