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

Fri Jul 3 06:55:50 UTC 2015

Hi

On 02.07.2015 14:13, Siddhesh Suthar wrote:
> 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.

I see, if you are not tracking learnt words, then you won't be able to continue at a more detailed 
point when restarting the activity later than the last completed level.

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

No strong opinion on these options. Both would serve your needs. JSON format might have the 
advantage to be more flexible with respect to future extensions.

>   iii) Activity base

I think you misunderstood here: ActivityBase would be a candidate to hold the current progress stats 
at runtime and be responsible for loading (activity start) and saving  (activity stop) counters to 
i) or ii)

>
> 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. :)

So if I understood correctly you want to achieve 2 things:

1. store activity progress in order to be able to resume at the last non-completed level when 
starting the activity later.

After what you said for this it should be enough to store something like lastCompletedLevel (and 
maybe lastCompleted subLevel).

2. store success (win/loose ratio) in order to provide feedback to the user (and a possible future 
admin/teacher)

Storing a simple winCount + looseCount should be enough for that. We might want to reset these 
counters if an activity is restarted from the beginning. Maybe also good to provide a way for the 
user to reset these counters. Plus a config-setting to en-/disable the feature completely?

Holger

> Siddhesh
>
>
> On Thu, Jul 2, 2015 at 4:53 PM, Johnny Jazeix <jazeix at gmail.com <mailto:jazeix at gmail.com>> wrote:
>
>     From: Holger Kaelberer <hk at elberer.de <mailto: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 <mailto: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 <mailto:GCompris-devel at kde.org>
>      >> https://mail.kde.org/mailman/listinfo/gcompris-devel
>      >
>      >
>      >
>      >
>      > _______________________________________________
>      > GCompris-devel mailing list
>      > GCompris-devel at kde.org <mailto:GCompris-devel at kde.org>
>      > https://mail.kde.org/mailman/listinfo/gcompris-devel
>      >
>     _______________________________________________
>     GCompris-devel mailing list
>     GCompris-devel at kde.org <mailto: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
>