[GCompris-devel] Division - new activity
B.J.
bj at koupps.net
Fri Feb 12 20:30:43 UTC 2016
That¹s a good point. Are we trying to keep everything in the single app
then? I see the advantages to this, as well as de-cluttering by keeping
admin/config items in a separate app. I¹m sure I¹d be the wrong person to
ask too; I¹m always good either way, as long as students¹ access to that
part of the config is limited. Any other teachers w/input on this?
Alsowould it translate across platforms easily? I imagine iOS/Android
users would just d/l a separate (optional) app probably? Just thinking out
loud here
From: JAZEIX Johnny <jazeix at gmail.com>
Date: Friday, February 12, 2016 at 2:18 PM
To: <gcompris-devel at kde.org>
Subject: Re: [GCompris-devel] Division - new activity
On 02/12/16 21:00, B.J. wrote:
>
> My vote for ³yes², thinking you¹re completely right. Another option would be
> to bring back the separate config tool we had with the GTK version, with which
> one could easily lock or allow specific activitiesthis confines the focal
> skill set, but also allows independent practice for menu navigation, which is
> a skill that some students don¹t have yet. That way a learner walks through
> the specific skills the group is currently working on while still using the
> icons to navigate. Even better: maybe an option for activities to ³open up²
> (allow access) after specific ones are completed? Maybe too many ideas at
> once for this stage of development though
>
>
>
>
>
>
> B.J.
>
>
>
>
> From: Bruno Coudoin < <mailto:bruno.coudoin at gcompris.net>
> bruno.coudoin at gcompris.net>
> Date: Friday, February 12, 2016 at 1:31 PM
> To: < <mailto:gcompris-devel at kde.org> gcompris-devel at kde.org>
> Subject: Re: [GCompris-devel] Division - new activity
>
>
>
>
>
>
>
>
>
> Le 12/02/2016 13:12, Johnny Jazeix a écrit :
>
>
>>
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> talked to allon on irc and he gave me some ideas:
>>>>
>>>>
>>>> - we should let the user decide how many children to split the candies to,
>>>> or even how many candies to have in total
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>>
>> I'm not sure if it is a good idea to let the child decide by default how many
>> candies/children. Can be interesting for classrooms, but I'm not sure it's a
>> good idea for children at home, if they play alone?
>>
>>
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
> We don't have it at the moment but we have to stay open to these kind of
> requests. Teachers want to tune each activity to match the difficulty level
> they have in the classroom. This is a valid request and it goes in par with
> the administration module.
>
> The scenario is that the teacher configures all the GCompris to run an
> activity at a given level or with a specific configuration. Going further, we
> could let a teacher create a multi activity scenario in which instead of
> having a menu the children is proposed a sequence of activities (including
> specific level and config) to follow. I created a task to track this need:
> https://phabricator.kde.org/T1596
>
> I am on the early thinking on this and maybe wrong, feel free to discuss it.
>
> Bruno.
>
>
>
If I understand correctly, there are 2 things: having custom levels (let's
say easily, some .js data files in some directory and a configuration button
like in balancebox to use the default levels or the customs).
And the possibility to directly input in the activity the configuration we
want (for this activity, let's say two text fields, to input the number of
children and candies).
I agree that we should have the possibility to read custom datasets. But
for the second point, as you say, it goes more on admin part than directly
on the activity itself.
For the Gtk+ version, if I'm not wrong, the "text" activities had the
possibilities to create datasets. Was there some rule to decide if it is
directly on the activity or in configuration?
Johnny
_______________________________________________ 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/20160212/8643fee0/attachment.html>
More information about the GCompris-devel
mailing list