[Sugar-devel] Karma: bundle layout improve
Felipe López Toledo
zer.subzero at gmail.com
Fri Aug 14 20:10:05 EDT 2009
> Hmm, your proposal could work. Before I air my concerns, I don't think
> we should use the word "lesson" to refer to the tutorial part of a Karma
> lesson. Calling the union of lesson + exercise+game+lesson plan also a
> "lesson" is confusing. I prefer we call the 1st part of a karma lesson a
> "tutorial" or "reading". I think that will make things less confusing
> than using "lesson" twice in slightly different contexts.
+1 for "reading"
> There will likely be a lot of common assets between the tutorial, game,
> and exercise. Splitting them up entirely could create a lot of
> duplication as the same images and sounds are present in both. However,
> it also could make life easier for the programmer, who wouldn't have to
> prefix each image w/ "exercise" or "tutorial".
yes, I'm aware, but at the end it's an advantage to separate the content:
with the current design and common assets, if the coder is writing the
"game" an try to get an image from "exercise" will need to access
"assets / {lag-code | generic} / images/ exercise/ {imageFile}",
now... let's think, what if I want to take the "game" and merge it
with other lesson:
I will need to look inside the code and look for the common assets (in
order to copy them and move them).
and what if the {imageFile} already exists inside the common destiny
(exercise) folder?
need to rename some image and fix some code :S
I think keeping things in different folders will bring clearness of
what are we coding and where are the files stored. So, we will be able
to copy and just paste the whole file and everything will be working.
> I think we should change the current layout to reflect some of your
> points http://wiki.sugarlabs.org/go/Karma/Bundle_layout#Lesson
> but I am wary or separating the tutorial, exercise, and game so sharply
renamed "lesson" to "reading"
greetings
On Fri, Aug 14, 2009 at 8:13 AM, Bryan Berry<bryan at olenepal.org> wrote:
> On Fri, 2009-08-14 at 11:18 +0545, Christoph Derndorfer wrote:
>> 2009/8/14 Felipe López Toledo <zer.subzero at gmail.com>
>> Hello there
>>
>> I know we already talked about the Bundle_layout[ 1 ]
>> but, I suggest to reorganize Lesson structure using this:
>>
>> lesson_name/
>> index.html # lesson content
>> lesson/ # lesson folder
>> game/ # game folder
>> exercise/ #exercise folder
>> ....
>>
>> lesson, game and exercise folder will contain
>> index.html # the lesson, game or whatever
>> css/
>> js/
>> assets/
>> generic/
>> images/
>> audio/
>> video/
>> ...
>> {lang-Code}/
>> images/
>> audio/
>> video/
>> ....
>
> Hmm, your proposal could work. Before I air my concerns, I don't think
> we should use the word "lesson" to refer to the tutorial part of a Karma
> lesson. Calling the union of lesson + exercise+game+lesson plan also a
> "lesson" is confusing. I prefer we call the 1st part of a karma lesson a
> "tutorial" or "reading". I think that will make things less confusing
> than using "lesson" twice in slightly different contexts.
>
> Subzero, the benefit of your approach is that it makes it easier to
> reuse games and exercises in new lessons. This makes sense when an
> adding game can relatively easily be transformed into a subtraction
> game. At the same time, the related tutorial and exercise could easily
> be remade for subtraction.
>
> There will likely be a lot of common assets between the tutorial, game,
> and exercise. Splitting them up entirely could create a lot of
> duplication as the same images and sounds are present in both. However,
> it also could make life easier for the programmer, who wouldn't have to
> prefix each image w/ "exercise" or "tutorial".
>
> I think we should change the current layout to reflect some of your
> points http://wiki.sugarlabs.org/go/Karma/Bundle_layout#Lesson
> but I am wary or separating the tutorial, exercise, and game so sharply
>
> but let me think about this more ;)
>
>
> --
> Bryan W. Berry
> Technology Director
> OLE Nepal, http://www.olenepal.org
>
>
--
Felipe López Toledo
More information about the Sugar-devel
mailing list