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

[Holger Kaelberer]

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
>