[Sugar-devel] The quest for data

[Walter Bender]

On Mon, Jan 6, 2014 at 3:00 PM, Sameer Verma <sverma at sfsu.edu> wrote:
> 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?

I am not sure about TuxMath (or Tuxpaint, Scratch or Etoys) none of
which are native Sugar activities. But the behavior I described is
standard across native Sugar activities.

-walter
>>>
>>>> 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
>>
>>



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org