[GCompris-devel] saving the progress for Lang activity.

Thu Jul 2 12:13:35 UTC 2015

Hi,

1.  Here the activity comprise of
i) the preview of words
ii) three quiz mini games, In the last one we display only those words
which have voice available
iii) the spell game
-So for example lets say in level 5 we have 20 words and each of them have
voice data available then progress will be counted on the base of 100 (20
for preview, 60 for quizzes and 20 for spell).
- and if out of 20 only 10 words have voice available then total score is
90. and we count progress after previewing or correctly answering a
question. So in my point of view its a little activity specific.

2.  yes we are tracking success ( win or loose) and counting progress based
on that. But at the same time we are not tracking which word is learnt and
which not. we are counting the total correct submissions.

3.  yes the progress is level based we have to store progress for each
level, so the possible candidates i see now are
 i)   The settings file
 ii)  json-file in a user-writable QStandardPath, which could entirely be
managed on the qml-layer.
 iii) Activity base

4. 'consume'/'restore' the progress will be the activity itself. because
the progress is calculated at run time and its activity specific.

Thanks for your views, would like to hear from you based on these points
too. :)
Siddhesh

On Thu, Jul 2, 2015 at 4:53 PM, Johnny Jazeix <jazeix at gmail.com> wrote:

> From: Holger Kaelberer <hk at elberer.de>
> Date: 2015-07-01 21:02 GMT+02:00
> Subject: Re: [GCompris-devel] saving the progress for Lang activity.
> To: gcompris-devel at kde.org
>
>
> Hi,
>
> some random thoughts:
>
> - What is "progress"? Simply a <levels-done>/<levels-max>? Might be
> enough for many activities. Or do we also want to consider sublevels?
> Or do we have to consider an activity-specific "progress" beyond
> levels/sublevels? (How would this look like for the lang-activities?
> Thinking of an index into a word-list or so ...)
>
> - Do we also want to track success (win vs. loose) in this way to
> allow for a teacher to react to pupils problems. (A feature that was
> talked about in the context of a live feedback to a teacher via
> admin-interface call.)
>
> - How to store it? A config/ini-file in the sense of seperate
> QSettings instance would probably mean to code it in C++. If we're
> only talking about a <levels-done>/<levels-max> percentage the
> settings file we have so far could also be reused to store progress in
> an [SomeActivity] group. An option could be to store things in a
> json-file in a user-writable QStandardPath, which could entirely be
> managed on the qml-layer. Not sure if using a database on the (client)
> device is necessary or of benefit.
>
> - Good idea to handle the basics of saving/restoring progress in
> ActivityBase. At least simple (level/sublevel-based) progress
> information could be tracked by the base class. Maybe with the option
> to extend it by a concrete activity if there is a need for activity
> specific progress details?
>
> - How would 'consume'/'restore' the progress? Two candidates:
>
> 1. the activity itself, to restart at a given progress level.
>
> 2. An admin activity. In this case activity-specific progress/state
> might not be of use, because the presenting UI might not know about
> the activity specific context.
>
> Holger
>
> On 27.06.2015 22:20, JAZEIX Johnny wrote:
> >
> > Hi,
> >
> > to be more precise, the point here is to see how we can have a generic
> solution to provide activity
> > progress and status to users (either teachers, parents or even children).
> >
> > The proposed solution is to use a new config file containing only the
> statistics for all the activities.
> > Then, it should be easy to create views for teachers and users. I don't
> think saving it in a qml is
> > interesting (you probably misunderstood why I was talking about qml,
> it's for the translations not
> > for saving stats).
> > A simple .ini file like for configuration could be enough. Then, we need
> to think if there is an
> > interest to use a database instead (maybe easier for integration with
> the admin interface? We can
> > even think of having an activity showing the progress :))?
> >
> > For the coding part, we should probably have a qml element doing all the
> job and use it in the
> > activities (maybe in the ActivityBase so loading/saving can be handled
> there).
> >
> > On 06/27/15 15:04, Siddhesh Suthar wrote:
> >>
> >> hello,
> >>
> >> I am porting language learning activities. Its almost complete. Now i
> have to save the progress of
> >> words which a user has learnt per lesson wise.
> >>
> >> The current idea I discussed with JohnnyJ is to save the progress in a
> qml file inside
> >> (resource/data) of the activity. then, we need to see how to define the
> format.
> >> There can be different approaches to it.
> >>
> >>  1. we store only the savedProgress corresponding to its lesson, and
> everything else for the
> >>     menuModel will be fetched from words.json through lang_api
> >>
> > To precise a little, savedProgress is a js variable storing while
> playing the activity the percent
> > of completed words for the current word category. It is not yet
> permanent so every time the user
> > restarts GCompris, the progress is reinitialized.
> >>
> >>
> >>  1. we also have to think if we can make this saving generic and where
> do we store it (as I don't
> >>     think it is great to save it in configuration file because then as
> we want this to be
> >>     potentially usable by other activities, putting these in the config
> file don't look like to be
> >>     a good idea).
> >>  2. johnny jazeix added:  I would prefer a special file for all the
> progresses because then, if
> >>     the teacher wants to retrieve all the stats for a child, only one
> file with only necessary
> >>     data would be better instead of all the config file.
> >>  3. In json, we can't translate (use qsTr()) but you can in qml, so it
> was more to provide the
> >>     translators all the strings in the same translation file they
> already use.
> >>
> > The last point is not useful for the current issue ;).
> >
> > Johnny
> >
> >> I would love to hear your ideas about it. Want to know what can be the
> best approach for it.
> >>
> >> Siddhesh suthar
> >>
> >>
> >>
> >> _______________________________________________
> >> GCompris-devel mailing list
> >> GCompris-devel at kde.org
> >> https://mail.kde.org/mailman/listinfo/gcompris-devel
> >
> >
> >
> >
> > _______________________________________________
> > GCompris-devel mailing list
> > GCompris-devel at kde.org
> > https://mail.kde.org/mailman/listinfo/gcompris-devel
> >
> _______________________________________________
> GCompris-devel mailing list
> GCompris-devel at kde.org
> https://mail.kde.org/mailman/listinfo/gcompris-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/gcompris-devel/attachments/20150702/25ffe5db/attachment.html>