More specifically, layout issues are (as said on irc, but noting those here for reference):

-on first dataset levels, in vertical mode, the areas go beyond the screen
-on first dataset levels, in horizontal mode at some sizes, the items overflow of their areas
-if screen ratio is close to square (but still considered horizontal), there is a big empty area (visible on lvl 6 to 9, and same on lvl 13 to 21)

I'm wondering if we should not have the image names in the dataset too so later we can choose which images to display

In D27583#624933, @jjazeix wrote:

I'm wondering if we should not have the image names in the dataset too so later we can choose which images to display

Can you elaborate a bit more about it? Are you talking about the images in mosaic.js file?

In D27583#625177, @dekumar wrote:

In D27583#624933, @jjazeix wrote:

I'm wondering if we should not have the image names in the dataset too so later we can choose which images to display

Can you elaborate a bit more about it? Are you talking about the images in mosaic.js file?

Yes, should we allow the possibility to the creator of the dataset to specify which images he wants? May be useful later for teachers or customisation. May be too much too.
@timotheegiet @echarruau does it make sense?

indeed, it would make sense to specify the image names in the dataset as you suggest.

Tested, the layout can still be improved a lot...
Though as it is not really part of the dataset changes, please keep it as it is, and I'll work on it after your changes are merged.

Still needed is to move the images names as part of the datasets, as suggested by Johnny.

In D27583#625474, @timotheegiet wrote:

Still needed is to move the images names as part of the datasets, as suggested by Johnny.

I would complete this work as part of the multiple dataset and update the diff soon.

In D27583#625473, @timotheegiet wrote:

Tested, the layout can still be improved a lot...
Though as it is not really part of the dataset changes, please keep it as it is, and I'll work on it after your changes are merged.

Thanks a lot for testing @timotheegiet . I would keep it as with the changes to layout I have done for now. Shall I open a new task for this purpose?

@dekumar I just opened a task for it T12809

In D27583#625178, @jjazeix wrote:

In D27583#625177, @dekumar wrote:

In D27583#624933, @jjazeix wrote:

I'm wondering if we should not have the image names in the dataset too so later we can choose which images to display

Can you elaborate a bit more about it? Are you talking about the images in mosaic.js file?

Yes, should we allow the possibility to the creator of the dataset to specify which images he wants? May be useful later for teachers or customisation. May be too much too.
@timotheegiet @echarruau does it make sense?

Hi,
It does really make sens. We need to think about the "step after". We may have in mind, (even if we do not do it at the end) that our server should allow to customise activities. The server could allow adding sublevels then presenting the attributes to fill. The variable therefore must be self explanatory, and we may have to add comments in front of the attributes to tell what they are and how to fill them. eg: //layout: describes the way the cells are displayed, eg: "layout": [ [6,4], [12,2] ],
In my case as programmer, thinking about the final user would force me to replace for example nbItems by nbOfCells which is clearer for the final user.
Here as final user, for example I do not know what multipleDatasetType is neither multipleDataset2.

There are mistakes in the multipledataset option text, see my online comments.

We could split multipledataset 2 2 in two different levels according to the number of items.

We could add an additional level but this includes quite a lots of change.
For this we need to have a different size between the model and the target. Let me explain you why.
In the current mosaic (single line option) children do not need to recall the order of the elements. They simply have to recognise one elements and put the same under. This is not what we are aiming at :)
Solution: have a smaller model that the target.

I recognize that the layout could be better if it would be centered. Nonetheless well done :) These are just details.

To sum up
multipledata1: as it is now but centered
multipledata2: as it is now but with a smaller model than the target (should be centered and we need to add an attribute to the multipledata)
multipledata3: first half of multipledata2
multipledata4: second half of multipledata2

I do not understand the multipledata variable you use.

In D27583#626328, @echarruau wrote:

In D27583#625178, @jjazeix wrote:

In D27583#625177, @dekumar wrote:

In D27583#624933, @jjazeix wrote:

I'm wondering if we should not have the image names in the dataset too so later we can choose which images to display

Can you elaborate a bit more about it? Are you talking about the images in mosaic.js file?

Yes, should we allow the possibility to the creator of the dataset to specify which images he wants? May be useful later for teachers or customisation. May be too much too.
@timotheegiet @echarruau does it make sense?

Hi,
It does really make sens. We need to think about the "step after". We may have in mind, (even if we do not do it at the end) that our server should allow to customise activities. The server could allow adding sublevels then presenting the attributes to fill. The variable therefore must be self explanatory, and we may have to add comments in front of the attributes to tell what they are and how to fill them. eg: //layout: describes the way the cells are displayed, eg: "layout": [ [6,4], [12,2] ],
In my case as programmer, thinking about the final user would force me to replace for example nbItems by nbOfCells which is clearer for the final user.
Here as final user, for example I do not know what multipleDatasetType is neither multipleDataset2.

@echarruau Hi, Thanks for the review. I would rename the variable with good names and add comments too as described by you.

In D27583#626331, @echarruau wrote:

There are mistakes in the multipledataset option text, see my online comments.

We could split multipledataset 2 2 in two different levels according to the number of items.

We could add an additional level but this includes quite a lots of change.
For this we need to have a different size between the model and the target. Let me explain you why.
In the current mosaic (single line option) children do not need to recall the order of the elements. They simply have to recognise one elements and put the same under. This is not what we are aiming at :)
Solution: have a smaller model that the target.

I recognize that the layout could be better if it would be centered. Nonetheless well done :) These are just details.

To sum up
multipledata1: as it is now but centered
multipledata2: as it is now but with a smaller model than the target (should be centered and we need to add an attribute to the multipledata)
multipledata3: first half of multipledata2
multipledata4: second half of multipledata2

@echarruau Regarding the layout rework, I had a discussion with @timotheegiet earlier as he going to do the rework when the multiple datasets are merged. As mentioned about the splitting the multiple datasets I would make that changes and update the diff.
You can find the task related with the changes to layout of the activity here and add comments here regarding the layout so it would be good to refer later https://phabricator.kde.org/T12809
Thanks :)

@jjazeix @echarruau @timotheegiet I have done all the requested changes expect adding a OK button. I would add it too and update the diff soon.
Thanks :)

We should have different objectives for all multiple datasets too, for now 1-2 and 3-4 have the exact same and it's not good, users need to know the difference between the datasets.
Also, you should probably add the variable that will be used to scale the model with a minimal handling, even if @timotheegiet is going to rework after.

In D27583#645436, @jjazeix wrote:

We should have different objectives for all multiple datasets too, for now 1-2 and 3-4 have the exact same and it's not good, users need to know the difference between the datasets.
Also, you should probably add the variable that will be used to scale the model with a minimal handling, even if @timotheegiet is going to rework after.

@jjazeix I remember as told by @echarruau to give the objective short and same. And regarding the use of extra variable @timotheegiet told me to keep it as it is now when he would work on the rework of layout he won't required any variable to make all the changes.

Yes I said I was not sure I would need a variable, but actually as it will be a scaling depending on dataset content, it's better indeed to have a variable to define this mode within the dataset.

@jjazeix Once just confirm me regarding the use of 4 different states and should I access the all four variables for different datasets. I am sorry for my small confusion regarding it :)

In D27583#646913, @dekumar wrote:

@jjazeix Once just confirm me regarding the use of 4 different states and should I access the all four variables for different datasets. I am sorry for my small confusion regarding it :)

How would you code the feature of having a smaller grid? Not the whole code, can you tell the basic element?

In D27583#646961, @jjazeix wrote:

In D27583#646913, @dekumar wrote:

@jjazeix Once just confirm me regarding the use of 4 different states and should I access the all four variables for different datasets. I am sorry for my small confusion regarding it :)

How would you code the feature of having a smaller grid? Not the whole code, can you tell the basic element?

For each of the three grid namely selector, question, and the answer the height and width value of the grid is setup according to the number of columns and itemWidth defined in the Column item. So by changing the valuesof itemWidth and depending upon the numberofColumns the grid size can be scaled up or down.
Thanks!

Use 2 variables:

• "modelDisplayLayout" either "singleColumn" or "doubleColumn"
• "scaleGridRatio" which is a float number. Above 1, we will scale down the first, below one the second (@timotheegiet will decide on what we want to do with this variable later or how to handle it).

In D27583#645919, @dekumar wrote:

In D27583#645436, @jjazeix wrote:

We should have different objectives for all multiple datasets too, for now 1-2 and 3-4 have the exact same and it's not good, users need to know the difference between the datasets.
Also, you should probably add the variable that will be used to scale the model with a minimal handling, even if @timotheegiet is going to rework after.

@jjazeix I remember as told by @echarruau to give the objective short and same. And regarding the use of extra variable @timotheegiet told me to keep it as it is now when he would work on the rework of layout he won't required any variable to make all the changes.

I still think objectives should all be different. It makes no sense to propose same objectives but not same content. If there is a difference, users should be able to know about it when choosing the dataset.

Except this, seems ok for me as long as @timotheegiet updates the layout.

Hi,
I can not remember telling that objectives should be the same? Obviously
the objectives have to match the goals to be be achieved. It must be a
misanderstanding.
Emmanuel

Le dim. 19 avr. 2020 à 18:03, Johnny Jazeix <noreply@phabricator.kde.org> a
écrit :

jjazeix added a comment. View Revision
https://phabricator.kde.org/D27583

In D27583#645919 https://phabricator.kde.org/D27583#645919, @dekumar
https://phabricator.kde.org/p/dekumar/ wrote:

In D27583#645436 https://phabricator.kde.org/D27583#645436, @jjazeix
https://phabricator.kde.org/p/jjazeix/ wrote:

We should have different objectives for all multiple datasets too, for now
1-2 and 3-4 have the exact same and it's not good, users need to know the
difference between the datasets.
Also, you should probably add the variable that will be used to scale the
model with a minimal handling, even if @timotheegiet
https://phabricator.kde.org/p/timotheegiet/ is going to rework after.

@jjazeix https://phabricator.kde.org/p/jjazeix/ I remember as told by
@echarruau https://phabricator.kde.org/p/echarruau/ to give the
objective short and same. And regarding the use of extra variable
@timotheegiet https://phabricator.kde.org/p/timotheegiet/ told me to
keep it as it is now when he would work on the rework of layout he won't
required any variable to make all the changes.

I still think objectives should all be different. It makes no sense to
propose same objectives but not same content. If there is a difference,
users should be able to know about it when choosing the dataset.

*REPOSITORY*
R2 GCompris

*BRANCH*
arc2

*REVISION DETAIL*
https://phabricator.kde.org/D27583

*To: *dekumar, GCompris: Improvements, jjazeix, timotheegiet, echarruau
*Cc: *kde-edu, narvaez, apol

@echarruau @jjazeix No problem. I would update the objectives.
Thanks!

There is a problem in the multipledataset difficulty progression.
We have twice "Items are placed on single line with number of items up to 6" in a row, and it jumps directly to 16 items.
I would prefer to have the second multipledataset set to ""Items are placed on single line with number of items up to 8"
or
"Items are placed on multiple lines with number of items up to 8" if it does not fit.

Also I would prefer a shorter message:

Up to 6 items placed on single line would be enough for me.

In D27583#658719, @echarruau wrote:

There is a problem in the multipledataset difficulty progression.
We have twice "Items are placed on single line with number of items up to 6" in a row, and it jumps directly to 16 items.
I would prefer to have the second multipledataset set to ""Items are placed on single line with number of items up to 8"
or
"Items are placed on multiple lines with number of items up to 8" if it does not fit.

Also I would prefer a shorter message:

Up to 6 items placed on single line would be enough for me.

Thanks for the review @echarruau . I would update the datasets content and the objective as per your comments.

Just tested. It is ok for me now concerning the multipledataset part.

I have a question about layout. Could we not fit the height of the answer area to the height available on the screen. This would prevent to have very small place when dealing with 8 items in a row.

@echarruau : as I said before: I will redo the layout of the activity after the patch is pushed, to make sure it is optimized as much as possible in any case.