On Mon, Jan 6, 2014 at 3:00 PM, Sameer Verma <sve...@sfsu.edu> wrote: > On Mon, Jan 6, 2014 at 4:50 AM, Walter Bender <walter.ben...@gmail.com> wrote: >> On Mon, Jan 6, 2014 at 3:48 AM, Martin Dluhos <mar...@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 >>> de...@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 _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel