[GCompris-devel] saving the progress for Lang activity.
Johnny Jazeix
jazeix at gmail.com
Fri Jul 3 09:16:06 UTC 2015
Hi,
2015-07-03 8:55 GMT+02:00 Holger Kaelberer <hk at elberer.de>:
> 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.
>>
Progress in lang is also locale dependent. Also for this activity, it
is at "sublevel" level (the different categories) where we want to
know the progress.
>> 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.
>
yes, this was a potentiality. If we want to track which words are
learnt. But we can't know if the child want to restart from beginning
or from where if wanted. We still can add an option for this (global
or activity specific).
Moreover, words are shuffled at each activity start so it could be a
little more work to separate learnt words from non yet, merge them
again and start from the first non learnt word.
But, if we store words, I think we should separate the activity
progress from the config because it will potentially do a big file for
config.
>>
>> 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.
I would personally go with the json file. Only one file may be easier
to parse for display. And we separate config from progress.
Also, this would be easier to have specific settings.
We can even think of having three patterns (or more) already
pre-implemented in hte ActivityBase ("level progress", "sublevel
progress", "custom"), we set a variable in qml and it returns what we
need (a pair <levels-done>/<levels-max> for level, an array for
sublevel and a json object for custom for example).
>
>> 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)
>
The third possible choice was database but I think it will be trying
to kill a fly with a hammer if we have no more use for it.
>>
>> 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?
If we want ot reset counters, we also have to think if we want to
reset all counters or only specific ones. First clean means to remove
the file, second one means to clean up only part of the file.
Johnny
>
> 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
>>
> _______________________________________________
> GCompris-devel mailing list
> GCompris-devel at kde.org
> https://mail.kde.org/mailman/listinfo/gcompris-devel
More information about the GCompris-devel
mailing list