On Tue, Apr 12, 2011 at 1:56 PM, C. Scott Ananian wrote:
> On Mon, Apr 4, 2011 at 6:09 PM, C. Scott Ananian wrote:
>> I've posted a four week plan for XO-3 software exploration at
>> http://cananian.livejournal.com/62667.html
>>
>> Briefly:
>> April 4-8: Android
>> April 11-15: Chrome/ChromeOS/Na
On Tue, Apr 12, 2011 at 5:45 PM, Peter Robinson wrote:
>> And, again, I have to remind folks that this is only *one* possible
>> forward path for Sugar-on-Tablets. This week I am examining a
>> ChromeOS-based option. http://cananian.livejournal.com/62667.html
>> describes the current plan of wor
> And, again, I have to remind folks that this is only *one* possible
> forward path for Sugar-on-Tablets. This week I am examining a
> ChromeOS-based option. http://cananian.livejournal.com/62667.html
> describes the current plan of work, and there will be further
> exploration of promising opti
On Tue, Apr 12, 2011 at 5:21 PM, C. Scott Ananian wrote:
> And, again, I have to remind folks that this is only *one* possible
> forward path for Sugar-on-Tablets. This week I am examining a
> ChromeOS-based option. http://cananian.livejournal.com/62667.html
> describes the current plan of work,
2011/4/12 NoiseEHC :
> What I do not get is this: what is the goal?
An excellent educational experience on tablet devices, within the
resources of the current Sugar community.
> Having an environment running on Android which can run the same XO bundles
> which are run by XO-1.x?
Ideally, yes. I
Cool!
What I do not get is this: what is the goal?
Having an environment running on Android which can run the same XO
bundles which are run by XO-1.x?
If the Sugar API has to be changed (adapted for some technical reason)
would you fork all activities?
Thanks,
NoiseEHC
On 2011.04.12. 19:56, C.
On Mon, Apr 4, 2011 at 6:09 PM, C. Scott Ananian wrote:
> I've posted a four week plan for XO-3 software exploration at
> http://cananian.livejournal.com/62667.html
>
> Briefly:
> April 4-8: Android
The report on the first week of work is now up at:
http://cananian.livejournal.com/62756.html
Bas
>>
> From a technical POV, no difference. From the POV of the learner,
> there are workflow and structural affordances we want to support. E.g,
> We want the kids to ask themselves: What, How, Why, For whom... We
> want to support the idea of selection, reflection... lots of details
> that we have
2011/4/5 NoiseEHC :
>
>>> What is a Portfolio?
>>
>> http://www.gse.harvard.edu/news/features/mi08012002.html
>>
>> -walter
>>
>
> Thanks!
> So it seems that the portfolio is the (maybe child selected) subset of the
> Journal. Am I right?
> How is it addressed in the current Sugar implementation? I
On Tue, Apr 5, 2011 at 1:00 PM, NoiseEHC wrote:
> What my real question is how is it different from a children owned web
> page, or a "publish at facebook" button?
The Journal should have a "publish to Moodle" (or to Mahara) bit of
glue. Add the ability (in Mahara/Moodle) to discuss those publish
>> What is a Portfolio?
> http://www.gse.harvard.edu/news/features/mi08012002.html
>
> -walter
>
Thanks!
So it seems that the portfolio is the (maybe child selected) subset of
the Journal. Am I right?
How is it addressed in the current Sugar implementation? If it is not
then is there a "specifi
On Tue, Apr 5, 2011 at 11:50 AM, NoiseEHC wrote:
>
>> The Journal and Portfolio are really important part of Walter's vision
>> of Sugar. They will be "system services", with strong enough
>> modularization to allow multiple competing implementations. I know
>> how that will work in web/nativecl
> The Journal and Portfolio are really important part of Walter's vision
> of Sugar. They will be "system services", with strong enough
> modularization to allow multiple competing implementations. I know
> how that will work in web/nativeclient model. I'm not certain how
> that works on Androi
On Tue, Apr 5, 2011 at 7:23 AM, NoiseEHC wrote:
> Hi Scott!
>
> The IAEP thread if I am not mistaken is this:
> http://lists.sugarlabs.org/archive/iaep/2011-February/012522.html
>
> When last time I proposed similar things on the mailing list all I have
> got were:
> 1. Do not tell others what to
Thanks for your links to the mailing list threads. That's handy to
have at my fingertips.
I agree that the activities are key. "Transparent" compatibility is
probably impossible, but I hope that porting the activities will not
be too hard. Minimizing unnecessary API changes and writing a good
p
Hi Scott!
The IAEP thread if I am not mistaken is this:
http://lists.sugarlabs.org/archive/iaep/2011-February/012522.html
When last time I proposed similar things on the mailing list all I have
got were:
1. Do not tell others what to do!
2. CADT
3. I want others to drop all sugar code now!
4. Pe
I've posted a four week plan for XO-3 software exploration at
http://cananian.livejournal.com/62667.html
Briefly:
April 4-8: Android
April 11-15: Chrome/ChromeOS/NativeClient
April 18-22: Get down & dirty with mesh
April 25-29: Yanking legacy Sugar codebase into the future
May 2-6: in Uruguay to p
17 matches
Mail list logo