[Sugar-devel] The quest for data

Sameer Verma sverma at sfsu.edu
Mon Jan 6 15:00:06 EST 2014


On Mon, Jan 6, 2014 at 4:50 AM, Walter Bender <walter.bender at gmail.com> wrote:
> On Mon, Jan 6, 2014 at 3:48 AM, Martin Dluhos <martin at gnu.org> wrote:
>> On 4.1.2014 10:44, Sameer Verma wrote:
>>
>>> True. Activities do not report end times, or whether the frequency
>>> count is for the number of times a "new" activity was started, or if
>>> it was simply a resumption of the previous instance. Walter had
>>> indicated that thre is some movement in this direction to gather end
>>> times.
>>
>> This would be indeed very useful. Is anyone working on implementing these features?
>
> The frequency count is a count of the number of times an instance of
> an activity has been opened. There number of new instances can be
> determined by the number of instance entries in the Journal.
>

Walter,
>From a conversation we had some time ago, you had pointed out that
TuxMath does not necessarily stick to this regimen. Every time a one
resumes an instance, it gets counted as a new instance. I haven't gone
back to verify this, but how consistent is this behavior across
activities? Can this behavior be standardized?

>>
>>> Yes, the methods that use the datastore as a source rely on the
>>> Journal, but the sugar-stats system does not. I believe it collects in
>>> GNOME as well.
>>
>> Have you done any processing, analysis, or visualization of the sugar-stats
>> data? Is that something that you are planning to integrate into OLPC Dashboard?
>
> There is an app for letting the user visualize their own stats.
> (Journal Stats). Could use some love and attention.
>

This is an excellent example of providing meaningful feedback with
respect to the scope. To borrow the Zoom metaphor, I see the Journal
stats to be at the level when the scope is local to the child. The
same scope zooms out at the level of the teacher, principal, district
education officer, MoE, etc.

cheers,
Sameer

>>
>>> 4) The reporting can be done either via visualization, and/or by
>>> generating periodic reports. The reporting should be specific to the
>>> person(s) looking at it. No magic there.
>>
>> I think that many questions (some of which we already mentioned above) can be
>> answered with reports and visualizations, which are not deployment specific. For
>> example, those you are targeting with OLPC dashboard.
>>
>>>
>>> How the data will be used remains to be seen. I have not seen it being
>>> used in any of the projects that I know of. If others have seen/done
>>> so, it would help to hear from them. I know that in conversations and
>>> presentations to decision makers, the usual sore point is "can you
>>> show us what you have so far?" For Jamaica, we have used a basic
>>> exploratory approach on the Journal data, corroborated with structured
>>>  interviews with parents, teachers, etc. So, for instance, the data we
>>> have shows a relatively large frequency of use of TuxMath (even with
>>> different biases). However, we have qualitative evidence that supports
>>> both usage of TuxMath and improvement in numeracy (standardized test).
>>> We can support strong(er) correlation, but cannot really establish
>>> causality. The three data points put together make for a compelling
>>> case.
>>
>> I think this is a really important point to emphasize: None of these approaches
>> to evaluation provides the complete picture, but all of these used in aggregate
>> can provide useful insights. Here at OLE Nepal, we already use standardized
>> testing to compare students performance before and after the program launch. We
>> also follow up with teachers through conversations using surveys on regular
>> support visit. I agree with Sameer that supplementing those with statistical
>> data can make for a much stronger case.
>>
>> Martin
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at lists.laptop.org
>> http://lists.laptop.org/listinfo/devel
>
>
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
>
>



More information about the Devel mailing list