From bryan at olenepal.org Thu Jan 1 20:50:40 2009
From: bryan at olenepal.org (Bryan Berry)
Date: Thu, 01 Jan 2009 17:50:40 -0800
Subject: [Sugar-devel] How to Make Activity Designers Happy , Parts I and II
Message-ID: <1230861040.17108.4.camel@hitman>
This is a draft of a multi-part article I plan to post to OLPC News.
It is very long but I would very much appreciate your opinions and
feedback. Your input will make it a better article once published.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
This OLPC project seems to be going pretty well as of late December
2008. G1G1 v2 is well underway, there are a number of successful pilots
going on, and a number of larger-scale pilots will come online this
spring and coming summer.
Still, there is a big gaping whole in the middle of our little education
project. There just aren't enough activities. Mind you, we have some
seriously awesome activities such as Etoys, Scratch, TamTam, and others.
We have tremendous depth but very limited breadth.
By breadth, I mean interactive activities for language, history,
geology, health, etc. In order to expand the range of activities, we
need to recruit a lot more activity developers and make it dead-simple
for them to contribute.
But Which Developers?
Let's think about who we want to recruit. We're talking about breadth
here so we need experts on Nepali grammar, Pashto vocabulary, Philippine
history, and Andean geography. The good news is that there are
technically-oriented people out there that know these things and want to
help.
We already have a hardcore team of dedicated hackers. We need them for
the work that hackers excel at: building infrastructure, testing the
limits of new systems. But now we need a different class of developer,
those that are focused on the presentation, game play and not system
internals.
Based on these characteristics, let's call these people
designers. The good news is that there are lots of
designers-particularly in developing countries-that want to contribute
to OLPC. The bad news is that they don't know python. or GTK+. They may
not even be familiar with linux. They do know HTML, CSS, Javascript, and
Adobe Flash. Allow me to explain.
Due to rise of the Internet and related boom in outsourcing, the vast,
vast majority of programmers in developing countries are web developers
(according to my own grossly unscientific survey). The rise of the
Internet has also led a lot of talented graphic designers in developing
and developed countries to learn web technologies. I even
wager that CSS/HTML/Javascript will become the de facto GUI technologies
in a few years time. PyGTK won't take over the
world nor will VB.net.
The popular term for this triumvirate of technologies is AJAX, with the difference
that AJAX applications typically require communication with a remote
server. I propose using web technologies for completely offline
activities. Adobe's Flash is basically a variant of AJAX that uses
dialects of Javascript (Actionscript) and
XML (MXML).
Very few programmers in the developed world get paid to write desktop
linux apps. Still, open-source developers find learn and build pygtk,
mono, and KDE apps in their free-time. Developers in the developing
world are extremely enthusiastic about FOSS but not nearly as prolific
in creating open-source software due to a phenomenon I
call the "FOSS-Nepal Paradox."
The FOSS Nepal community has won the award for best celebration of Software Freedom day for two years in a running. Despite all this enthusiasm the FOSS Nepal community is not very prolific in producing open-source code. The reason for this is that Nepal is not a wealthy country and that Open-Source is expensive to produce.
Open-Source is Expensive
Open-source software voraciously consumes a resource even more valuable
than hard cash, programmer time. Linus Torvalds could afford to spend
some of the most productive years of his life working without immediate
financial benefit. He could slack off in his classes without fear of
unemployment upon graduation. I doubt his parents were counting on him
to support them financially once he got a job.
Most talented Nepali programmers I know do not have those luxuries. They
are under a lot of pressure to support their parents and extended
families, financially and otherwise. So Nepalis, Bangladeshis, Peruanos,
etc. certainly have the passion and ability to contribute to open-source
but their free time is significantly more limited.
This doesn't mean that we should rely on developers from rich countries.
We simply need to radically lower the amount of time required to create
learning activities. I believe that many, many developers in the
developing world can contribute 3-5 hours per week. To make those few
hours productive we need to rework the default activity framework.
>From what I can tell, the primary design goals of the default PyGTK
activity
framework are as follows:
- Give the programmer maximum flexibility
- Fully exploit
the XO's hardware features
- Mesh nicely with Sugar
These three goals are laudable and their hacker roots are obvious. The
problem is that these goals maximize the technology's potential rather
than programmer productivity. We need reach beyond the vi/emacs crowd
(Note: I wrote this article using emacs) to thos folks that the masters
of Photoshop, Adobe Illustrator, Eclipse, and GIMP.
I propose a new set of design goals:
- Allow activity designers to quickly build activities utilizing
widely-used tools.
- Quickly reward effort with working behavior
- Mesh nicely with the Sugar UI
It's OK to be Opinionated
We need an opinionated activity framework that makes infrastructure
choices for the designer so that she can focus presentation and
gameplay. Some may recognize this as the principle of Convention Over Configuration, a principle that two of the most popular web frameworks, Django and RubyOnRails, adhere to. Now a lot of geeks don't like Convention over Configuration--perl hackers especially--but they sure do allow you to create nice applications very quickly.
Establishing an "opinionated" activity framework will in no way limit
the freedom of those hackers who want to go their own way. They can
always build their own activities from whatever tools they choose. The
whole point of a framework is to help people get started quickly but it
doesn't constrain anyone.
This concludes part I. Here are some tantalizing morsels from Part II
of "How to Make Activity Designers Happy,"
- Where it's at: HTML, CSS, Javascript, and *gasp* Flash
- Nepal's Content Development Experience
- Aren't Kids going to create all learning activities so we don't
have to?
Bryan Berry is the Technology Director of OLE Nepal and deadbeat co-editor of
OLPCNews.com. Christopher Marin contributed his knowledge about all
things web to this article
In part 1, I talked about the paradoxical
nature of open-source communities in developing countries, flaws in
the current default activity development framework, and the urgent
need for a new framework that makes activity designers happy.
By happy, I mean that the framework rewards their efforts almost
immediately (roughly 15 minutes of effort) and it lets them focus on
presentation and gameplay rather than infrastructure. Last time I
offered some vague ideas how this framework might function. This time
I will provide more details how this framework could work and why.
Let's Ride The Internet Wave
The Internet is the 300-pound gorilla in the software-engineering room
it will eat virtually everything, including your favorite desktop GUI
framework. All of the IDE's bend over backwards to support coding of
webapps, whether it is emacs, eclipse, or even vim. The software
industry is making huge investments into web technologies that support
the triumvirate of HTML/CSS/Javascript, witness Google's investment in
V8 javascript compiler and
Apple's investment in Webkit. I speculate
that there are many, many more developers working on GUI toolkits for
the web browser- such as JQuery, Prototype, Script.aculo.us-than for
GNOME or KDE desktop frameworks.
The web will keep innovating at a breakneck pace. We need to ride that
wave of innovation.
In the early days of OLPC, we all had a lot of grandiose and
impractical ideas. The educational systems of developing countries
would change overnight into constructionist hotbeds. Kids would build
their own activities, eliminating the need for large investments in
content development. A million PyGTK apps with built-in collaboration
and "View-Source" key would spontaneously bloom . . . Well, we're
older and wiser now. School systems anywhere are not blank slates that
we can redraw from scratch using cheap laptops and Etoys. Similarly,
we cannot expect thousands of developers to flock to a framework
(PyGTK) that is not commercially popular.
Developing Country Developer Economics
As I wrote in Part I, the economics of open-source in developing
countries is quite different than that in the developed
world. Developers there have ample enthusiasm for open-source but much
less time to contribute.
We need to lower the barrier of entry significantly in order to use
their talents. In fact, we need to entice non-programmers such as
graphic designers. In my limited experience, graphic designers are
much better at designing learning activities than programmers. They
better appreciate aesthetics and visual story-telling.
Web designers layout their work using CSS and (X)HTML. They implement
user interaction and animations using Javascript. They design their
work using Photoshop, GIMP, Adobe Illustrator, and sometimes
Eclipse. They know the features and dark areas of the Firefox web
browser. Sugar infrastructure developers, these people are your
customers. We need KARMA to enable them to quickly buidl activities
for the XO without having to learn a whole new skillset. From a
programmatic point of view, Browse needs to behave as much as possible
like Firefox. Any discrepancy will distract activity designers from
the more rewarding parts of activity development.
Building Good KARMA
Before we get too far, let's give this new activity framework a name
so I can save us all a lot of excess verbiage. I call it KARMA,
because the word is loosely-related to Nepal, my current residence,
and I like to think creating open-source learning activities gives an
individual good karma. Coincidentally, it is also the first two
syllables of Rabi Karmacharya's last name--an individual put a ton of
hard work and personal sacrifice into the OLPC project in Nepal.
Well, I haven't actually made up my mind what the core technologies of
KARMA
should be. I need your help to work it out. Before I get into the
technologies, here are my priorities. 1) These tools maximize
programmer productivity and 2) are open-soure. Priority #1 is much
more important than #2. 100% purely open-source activities that don't
exist don't help kids learn. The current pygtk framework is purely
open-source but you have to become a unix programmer to use it. As I
noted in Part I, the vast, vast majority of programmers in the
developing world are web developers and a successful activity
framework will allow them to re-use their existing skills and tools.
I have settled on HTML and CSS for the presentation but it is tougher
to decide on the scripting toolset and on persistent data
storage. Flash handles animations really well and it is easy to
integrate audio into the animations. Adobe sells some really nice
WYSIWYG tools for editing animation and adding audio. A lot of
developers know flash so there is a large pool of talent we can draw
from. Did I forget to mention that Flash is proprietary?
The closed-source issue not withstanding, Flash is the tool to
use. Some may be upset that Flash doesn't lend itself to "View Source"
functionality but learning programming is not the sum total of
education. Kids can do all the programming they ever want to w/ the
excellent Etoys and Scratch. Sorry to sound like a broken record, but
Afghani kids won't be able to view the source of Pashto grammar
activities that don't exist, let alone interactively learn the rules
of Pashto grammar.
Flash Ain't Open-Source
Flash is not _as_ closed-source as other software applications like
Windows. The Adobe has published the specification for their SWF file
format and the ActionScript 3.0 compiler is open-source. However, the
Adobe's development tools such as Adobe Animator, Illustrator,
Photoshop, etc. are not open-source. Nor is Adobe's flash player
plugin. There is the open-source Gnash player but it does not fully
support Actionscript 3 or Flash version 9. Rob Savoye and his team at
Open Media Now do a great job but they seriously lack resources. Note:
Rob
Savoye, please correct my egregious errors.
Javascript Isn't Ready
I put in a good number of research hours into this article. I really,
really wanted to find a pure javascript framework that could compete
with Flash. I couldn't find one that does. There are libraries like
DOJO, JQuery, and Processing.js
http://ejohn.org/blog/processingjs/. Unfortunately, there aren't any
IDE's that provide WYSIWYG animation editing for these tools. Every
try to edit photos from a text editor? It's painful, really
painful. So while real programmers use emacs (or vi, joe, sam, etc.),
designers use WYSIWYG GUI's.
Sadly, Javascript can't use the Graphics Processing Unit like Flash
can. Ouch, it's a pain in the ass to couple animations with sound
files. Based on my research so far, pure javascript won't be able to
compete with Flash for at least the next several years. Please prove
me wrong. Please post a comment to this article linking to some
Javascript wonderfulness that pulls even with Flash.
I will continue with the assumption that KARMA will use flash. I will
happily revise this article ex post facto if someone in cyberspace
points me to a pure javascript solution that makes activity designers
happy.
Building Momentum for Gnash
I believe that the best way to increase interest in fully open-source
flash is to make Flash more central in the evolving open-source
education stack rather than minimizing its role. We definitely cannot
wait for Gnash to fully support every feature of the proprietary flash
before we begin using it. Open-Source starts when a single developer
"scratches an itch" as the proverb goes. It follows then that the best
way to bring Gnash up to speed we need to create a nasty, festering
sore that irritates the open-source community into action.
Moving the Conversation Forward
Many people will likely hate my promotion of Flash for learning
activities. It's OK if you hate me and Flash. I do hope you recognize
that we need a more developer-centric activity framework that uses web
technologies.
I have a lot more to write about Nepal's experiences developing
learning activities and my ideas on Convention over Configuration in
sugar activities. I will save those for another day.
--
Bryan W. Berry
Technology Director
OLE Nepal, http://www.olenepal.org
From michael at laptop.org Thu Jan 1 23:41:46 2009
From: michael at laptop.org (Michael Stone)
Date: Thu, 1 Jan 2009 23:41:46 -0500
Subject: [Sugar-devel] [IAEP] How to Make Activity Designers Happy ,
Parts I and II
In-Reply-To:
References: <1230861040.17108.4.camel__8009.18864920295$1230861178$gmane$org@hitman>
Message-ID: <20090102044146.GA3164@didacte.laptop.org>
On Thu, Jan 01, 2009 at 11:06:07PM -0500, Chris Ball wrote:
> > Many people will likely hate my promotion of Flash for learning
> > activities. It's OK if you hate me and Flash. I do hope you
> > recognize that we need a more developer-centric activity framework
> > that uses web technologies.
>
>Making activity development easier is an unarguably fine goal, but I
>don't think there are any simple solutions.
So what?
> For example, do we even have a Flash editor under Linux?
What does this have to do with Brian's real points about the economic
factors underlying availability of programmer time?
(Tangentially: where did the GIMP, Inkscape, and Blender come from?)
> Is the first instruction on how to write activities for someone in the
> developing world going to be "First, pirate a copy of Windows and
> Adobe Flash Professional, and then.."?
Can we propose a workable counter-offer?
Michael
From bryan at olenepal.org Fri Jan 2 00:32:39 2009
From: bryan at olenepal.org (Bryan Berry)
Date: Thu, 01 Jan 2009 21:32:39 -0800
Subject: [Sugar-devel] How to Make Activity Designers Happy ,
Parts I and II
In-Reply-To:
References: <1230861040.17108.4.camel__8009.18864920295$1230861178$gmane$org@hitman>
Message-ID: <1230874359.17108.16.camel@hitman>
On Thu, 2009-01-01 at 23:06 -0500, Chris Ball wrote:
> Hi Bryan,
>
> > Sadly, Javascript can't use the Graphics Processing Unit like Flash
> > can. Ouch,
>
> The XO doesn't have much of a GPU, so I wouldn't be so worried about
> this. Any Javascript renderer that backs onto cairo will get as any
> other graphics on the XO.
>
> > Many people will likely hate my promotion of Flash for learning
> > activities. It's OK if you hate me and Flash. I do hope you
> > recognize that we need a more developer-centric activity framework
> > that uses web technologies.
>
> Making activity development easier is an unarguably fine goal, but I
> don't think there are any simple solutions. For example, do we even
> have a Flash editor under Linux? Is the first instruction on how to
> write activities for someone in the developing world going to be "First,
> pirate a copy of Windows and Adobe Flash Professional, and then.."?
If they know what computer programming is, they have likely already done
the above steps.
Developing learning activities requires the developer already know
something about programming. In Nepal, China, India that means they have
at least a pirated copy of Windows and possibly Adobe Flash. If they
have linux, that means that some time ago they had pirated Windows which
they used to learn about linux.
If they don't have a pirated copy of Windows then they don't have
computers to develop on.
The key is that the vast majority of programmers in the world are not
linux programmers and my 7 years experience in the developing world has
taught me that the vast majority of software developer there are web
developers.
The resulting activities have to be open-source but the IDE used to
develop them doesn't have to be.
All activities on the XO don't have to be hackable. Hacking teaches
important thinking processes but it doesn't teach grammar, art history
or biology. Someone can create a less-hackable-but open-source- flash
activity that teaches Tibetan art. It accomplishes the goal of teaching
the elements of Tibetan mandala paintings. That's a fair compromise.
There are 200-300 flash developers in Nepal and about 2 guys that have
written pygtk apps (maybe once). The numbers are more extreme in
Bangladesh, India, Pakistan. We can't bet on mass #'s of programmers
suddenly becoming linux developers in order to vastly increase the # of
activities.
--
Bryan W. Berry
Technology Director
OLE Nepal, http://www.olenepal.org
From gary at garycmartin.com Fri Jan 2 08:06:44 2009
From: gary at garycmartin.com (Gary C Martin)
Date: Fri, 2 Jan 2009 13:06:44 +0000
Subject: [Sugar-devel] How to Make Activity Designers Happy ,
Parts I and II
In-Reply-To: <1230874359.17108.16.camel@hitman>
References: <1230861040.17108.4.camel__8009.18864920295$1230861178$gmane$org@hitman>
<1230874359.17108.16.camel@hitman>
Message-ID:
On 2 Jan 2009, at 05:32, Bryan Berry wrote:
> There are 200-300 flash developers in Nepal and about 2 guys that have
> written pygtk apps (maybe once). The numbers are more extreme in
> Bangladesh, India, Pakistan. We can't bet on mass #'s of programmers
> suddenly becoming linux developers in order to vastly increase the #
> of
> activities.
I've done a lot of flash development and design in the past but was
driven away by the cost & closed nature of the IDE, and the _shocking_
breaks in compatibility from version to version ? made supporting any
set of non trivial source code a nightmare past each version release,
you were often better to re-write from scratch ? now that's expensive...
To cut to the chase, the 200-300 flash developers in Nepal can already
use their copies of Flash, Photoshop, and Illustrator to create rich
media experiences on the XO, if they want to. All they need do is
stick to creating/exporting Flash Player 5 or perhaps Flash Player 6
compatible swf's, avoid proprietary codecs, and do at least some
minimal testing on an XO to make sure they haven't over cooked on the
fancy effects so much that it's no longer usable***.
This work can be distributed right now as a .xol library bundle, or
with some code hacking as a real activity using the same back end that
Browse does (like the GMail and the more recent Help activity). I
understand there is some sugar planning to make a more efficient web
widget/canvas so that such activities can be more simply cooky-cut
from a template/demo activity (less duplication of boiler-plate code).
This approach also works for purely HTML/CSS/JavaScript developers.
*** very few developers actually want to design for lower end systems,
most wants their work full of shiny, spinning, anti-alised, alpha
composited eye candy... Achieving this AND making it perform
efficiently is not an easy task, so most don't spend the extra time.
--Gary
From bryan at olenepal.org Fri Jan 2 11:04:53 2009
From: bryan at olenepal.org (Bryan Berry)
Date: Fri, 02 Jan 2009 08:04:53 -0800
Subject: [Sugar-devel] How to Make Activity Designers Happy ,
Parts I and II
In-Reply-To:
References: <1230861040.17108.4.camel__8009.18864920295$1230861178$gmane$org@hitman>
<1230874359.17108.16.camel@hitman>
Message-ID: <1230912293.17108.41.camel@hitman>
On Fri, 2009-01-02 at 03:09 -0500, Chris Ball wrote:
> Hi Bryan,
>
> > Developing learning activities requires the developer already know
> > something about programming. In Nepal, China, India that means they
> > have at least a pirated copy of Windows and possibly Adobe Flash.
> > If they have linux, that means that some time ago they had pirated
> > Windows which they used to learn about linux.
>
> That sounds plausible, at least for pirated Windows. (I'm sure it's
> much harder to get a copy of Flash.)
not really. They sell dvds w/ pirated flash on the streets of Kathmandu.
The same is true for much of Asia. I don't know about Latin America.
> I'm not willing to incorporate "First, get a pirated copy of Windows
> and Flash" into my instructions for activity development, though.
The current setup requires the following of potential activity
designers:
First, learn linux. That may take you several months to become
comfortable with it. In particular you will have to learn the linux
filesystem well enough to manage file permissions and juggling
directories.
Next, Learn Python. This might take you several weeks
Then, learn the sugar idioms.
Finally, you're ready to get started on your first Sugar activity!
> We're supposed to be combating the inequity that says "we can create
> things on our computers because we're rich, but you don't get to do
> that on yours without breaking the law because you're poor". That
> inequity is just as much a part of the digital divide as everything
> else we're trying to bridge over, in my opinion.
umm, I thought we were trying to empower kids how to learn for
themselves. Be it grammar, math, science, history, etc.
I don't believe in the digital divide. I believe in the Quality Divide,
the huge quality differential b/w basic education for the world's poor
and the world's rich. That is the problem I am most focused on and
primary motivation for working on this project.
> It feels important to me to be able to say "Here's a software platform
> for you to start out with, and here's all of the software we used in
> the process of making it, which means there's nothing stopping you
> from learning to further it yourself". A true passing on of knowledge
> from one group to another, as equals.
Developers can write flash using vi and the SWF compiler from the
command line http://opensource.adobe.com/wiki/display/flexsdk/Download
+Flex+3
This paragraph reflects the opinion that developers should have to learn
an entirely new set of tools to develop activities. I tried to make it
very clear that developers in the developing world do not have time to
learn a whole new set of tools. If that point did not come across to you
or you disagree w/ that point, please let me know.
> I imagine this is the kind of debate where no-one really changes their
> mind; that's okay. As long as the viewpoint of software freedom as a
> foundational principle for Sugar (even in the face of extra convenience)
> is being represented and considered, I'm happy.
That foundational principle is very important to me. I do feel that
while the software and activities used on the XO have to be open-source,
the IDE's and other software tools used to build software for the XO do
not have to be open-source.
> Thanks,
>
> - Chris.
--
Bryan W. Berry
Technology Director
OLE Nepal, http://www.olenepal.org
From wadetb at gmail.com Fri Jan 2 12:30:48 2009
From: wadetb at gmail.com (Wade Brainerd)
Date: Fri, 2 Jan 2009 12:30:48 -0500
Subject: [Sugar-devel] [IAEP] How to Make Activity Designers Happy ,
Parts I and II
In-Reply-To: <1230912293.17108.41.camel@hitman>
References: <1230861040.17108.4.camel__8009.18864920295$1230861178$gmane$org@hitman>
<1230874359.17108.16.camel@hitman>
<1230912293.17108.41.camel@hitman>
Message-ID: <7087c32a0901020930g3a529a23tbc789fb4bddf8574@mail.gmail.com>
I think Bryan's idea is wonderfully practical. What's more, it sounds easy
to achieve. You just need a 'swf-activity' launcher, and a script to
sugarize .SWF files into .xo bundles which launch as fullscreen activities.
Building it around Browse is probably a bad idea (re: the .xol suggestion).
What's the point of loading up Firefox just to play a SWF file?
There is still a place for PyGTK. If you want the "real" Sugar, e.g.
collaboration, Journal interaction, the visual theme, etc. stick with
PyGTK. If you want a simple Pashto grammar activity and have Flash
programmers at your disposal, use Flash.
-Wade
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090102/ff41c9ca/attachment.htm
From walter.bender at gmail.com Fri Jan 2 12:46:24 2009
From: walter.bender at gmail.com (Walter Bender)
Date: Fri, 2 Jan 2009 12:46:24 -0500
Subject: [Sugar-devel] How to Make Activity Designers Happy ,
Parts I and II
In-Reply-To: <1230912293.17108.41.camel@hitman>
References: <1230861040.17108.4.camel__8009.18864920295$1230861178$gmane$org@hitman>
<1230874359.17108.16.camel@hitman>
<1230912293.17108.41.camel@hitman>
Message-ID:
Bryan, I appreciate you raising this discussion thread. Unequivocally,
We need to make it easier for everyone to contribute.
In regard to your essay, I think it is important in this discussion to
make a clearer distinction between (1) the constraints on FLOSS
development in the developing world (i.e., the need to get paid); (2)
the tools one uses for that work (e.g., Flash vs Javascript/HTML vs
Python); (3) the role that "educational content" providers might play
in development (i.e., who are they and are they primarily writing
software?); and (4) the pedagogy we are espousing (e.g., is
constructionism the only game in town?).
1. While others have also observed that there is a need for profit in
the developing world for software developers, this by no means
disqualifies FLOSS development. It just means that the profit comes
not from selling a license to a closed package, but getting paid, for
example, by providing a service. There is not necessarily new money to
be had and it will take time to redirect money in the system that is
directed towards FLOSS developers. But that doesn't suggest that FLOSS
should be abandoned. It is clear that at least for education (and
voting), FLOSS is *the* right way.
2. Low-cost/moderately powered hardware platforms do present some
constraints on what tools and solutions are suitable. Other
constraints include what skills are locally available and what rising
tides should be exploited. HTML/Javascript is probably the
lowest-hanging fruit, although Javascript performance on the OLPC-XO-1
hardware can be sluggish. But not as sluggish as Flash. It may be
worth someone making a concerted effort to help Rob fine-tune Gnash
(only Adobe can tune Flash) for the XO. The Sugar team will continue
to try to lower the barriers to developing native Sugar Activities and
putting Sugar wrappers around existing applications, be they written
in Javascript (e.g., SocialCalc) or Python or any other environment.
The foci are to provide ready access to the Journal and the
collaboration mechanisms ("convention over configuration"). (Wade's
note that arrived while I was composing this one is an example of what
we can do as a community to help individual development efforts.
3. While I am thrilled that some classroom teachers are beginning to
participate directly in the software development process (e.g.,
TurtleArt and Labyrinth), I am convinced that their major contribution
will be more at the level of integration. There is a wonderful
"curriculum" developed in Peru on community publishing that leverages
Record, Write, Browse, and Chat. It didn't involve any Javascript or
Flash, just thoughtful synthesis of the available tools. There are
holes in our repertoire that preclude certain types of curriculum
development: I am working on some presentation/portfolio tools, for
example. What other holes need filling? And I am curious as to your
experience working with teachers within the Etoys framework. Was that
too difficult for them to master? How could we make it more
accessible? And what are the roadblocks to developing web content for
Sugar and/or OLPC-XOs?
4. Constructionism is not the only way. Our strategy at Sugar Labs is
to make a platform that encourages more constructionism in the
learning process, but that it would be a matter of lowering the
barriers to entry, not closing doors to other approaches. To repeat a
well-wore analogy: you can read a book in either PDF or Wiki format,
but the chances that the reader will make annotations, add to a
discussion, and even add to the content are all much greater with a
Wiki because it has the proper affordances for such interventions.
Providing such affordances to the learning experience might be
motivated by a specific pedagogy, but it does not preclude other
approaches.
-walter
--
Walter Bender
Sugar Labs
http://www.sugarlabs.org
From tomeu at sugarlabs.org Fri Jan 2 13:18:47 2009
From: tomeu at sugarlabs.org (Tomeu Vizoso)
Date: Fri, 2 Jan 2009 19:18:47 +0100
Subject: [Sugar-devel] web-based activities (was Re: [IAEP] How to Make
Activity Designers Happy , Parts I and II)
Message-ID: <242851610901021018r4c84d249r8b348dc126c4bbe9@mail.gmail.com>
Hi,
without needing to get into what is better for our deployments, I do
see value in making easier to make Sugar activities using technologies
such as HTML, CSS, etc
Bryan, can we get into a more detailed view on what it would take
ideally to create a new activity using such activities? Which would be
the steps that an experienced web designer would need to take in order
to create a Sugar activity?
I'm sure that someone with basic knowledge of python could create some
tools that make it much more easier than it is today. Also have some
ideas about how those activities could interact with the journal and
other Sugar features.
Thanks,
Tomeu
On Fri, Jan 2, 2009 at 02:50, Bryan Berry wrote:
> This is a draft of a multi-part article I plan to post to OLPC News.
>
> It is very long but I would very much appreciate your opinions and
> feedback. Your input will make it a better article once published.
>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
> This OLPC project seems to be going pretty well as of late December
> 2008. G1G1 v2 is well underway, there are a number of successful pilots
> going on, and a number of larger-scale pilots will come online this
> spring and coming summer.
>
> Still, there is a big gaping whole in the middle of our little education
> project. There just aren't enough activities. Mind you, we have some
> seriously awesome activities such as Etoys, Scratch, TamTam, and others.
> We have tremendous depth but very limited breadth.
>
> By breadth, I mean interactive activities for language, history,
> geology, health, etc. In order to expand the range of activities, we
> need to recruit a lot more activity developers and make it dead-simple
> for them to contribute.
>
> But Which Developers?
>
> Let's think about who we want to recruit. We're talking about breadth
> here so we need experts on Nepali grammar, Pashto vocabulary, Philippine
> history, and Andean geography. The good news is that there are
> technically-oriented people out there that know these things and want to
> help.
>
> We already have a hardcore team of dedicated hackers. We need them for
> the work that hackers excel at: building infrastructure, testing the
> limits of new systems. But now we need a different class of developer,
> those that are focused on the presentation, game play and not system
> internals.
>
> Based on these characteristics, let's call these people
> designers. The good news is that there are lots of
> designers-particularly in developing countries-that want to contribute
> to OLPC. The bad news is that they don't know python. or GTK+. They may
> not even be familiar with linux. They do know HTML, CSS, Javascript, and
> Adobe Flash. Allow me to explain.
>
> Due to rise of the Internet and related boom in outsourcing, the vast,
> vast majority of programmers in developing countries are web developers
> (according to my own grossly unscientific survey). The rise of the
> Internet has also led a lot of talented graphic designers in developing
> and developed countries to learn web technologies. I even
> wager that CSS/HTML/Javascript will become the de facto GUI technologies
> in a few years time. href="http://en.wikipedia.org/wiki/Pygtk">PyGTK won't take over the
> world nor will VB.net.
>
> The popular term for this triumvirate of technologies is href="http://en.wikipedia.org/wiki/AJAX">AJAX, with the difference
> that AJAX applications typically require communication with a remote
> server. I propose using web technologies for completely offline
> activities. Adobe's Flash is basically a variant of AJAX that uses
> dialects of Javascript ( href="http://en.wikipedia.org/wiki/Actionscript">Actionscript) and
> XML (MXML).
>
> Very few programmers in the developed world get paid to write desktop
> linux apps. Still, open-source developers find learn and build pygtk,
> mono, and KDE apps in their free-time. Developers in the developing
> world are extremely enthusiastic about FOSS but not nearly as prolific
> in creating open-source software due to a phenomenon I
> call the "FOSS-Nepal Paradox."
>
> The href="http://wiki.fossnepal.org/index.php?title=The_FOSS_Nepal_Community">FOSS Nepal community has won the award for best celebration of Software Freedom day for two years in a running. Despite all this enthusiasm the FOSS Nepal community is not very prolific in producing open-source code. The reason for this is that Nepal is not a wealthy country and that Open-Source is expensive to produce.
>
> Open-Source is Expensive
>
> Open-source software voraciously consumes a resource even more valuable
> than hard cash, programmer time. Linus Torvalds could afford to spend
> some of the most productive years of his life working without immediate
> financial benefit. He could slack off in his classes without fear of
> unemployment upon graduation. I doubt his parents were counting on him
> to support them financially once he got a job.
>
> Most talented Nepali programmers I know do not have those luxuries. They
> are under a lot of pressure to support their parents and extended
> families, financially and otherwise. So Nepalis, Bangladeshis, Peruanos,
> etc. certainly have the passion and ability to contribute to open-source
> but their free time is significantly more limited.
>
> This doesn't mean that we should rely on developers from rich countries.
> We simply need to radically lower the amount of time required to create
> learning activities. I believe that many, many developers in the
> developing world can contribute 3-5 hours per week. To make those few
> hours productive we need to rework the default activity framework.
>
> >From what I can tell, the primary design goals of the default PyGTK
> activity
> framework are as follows:
>
> - Give the programmer maximum flexibility
- Fully exploit
> the XO's hardware features
- Mesh nicely with Sugar
>
> These three goals are laudable and their hacker roots are obvious. The
> problem is that these goals maximize the technology's potential rather
> than programmer productivity. We need reach beyond the vi/emacs crowd
> (Note: I wrote this article using emacs) to thos folks that the masters
> of Photoshop, Adobe Illustrator, Eclipse, and GIMP.
>
> I propose a new set of design goals:
>
>
> - Allow activity designers to quickly build activities utilizing
> widely-used tools.
> - Quickly reward effort with working behavior
> - Mesh nicely with the Sugar UI
>
>
> It's OK to be Opinionated
>
> We need an opinionated activity framework that makes infrastructure
> choices for the designer so that she can focus presentation and
> gameplay. Some may recognize this as the principle of href="http://en.wikipedia.org/wiki/Convention_over_Configuration">Convention Over Configuration, a principle that two of the most popular web frameworks, Django and RubyOnRails, adhere to. Now a lot of geeks don't like Convention over Configuration--perl hackers especially--but they sure do allow you to create nice applications very quickly.
>
> Establishing an "opinionated" activity framework will in no way limit
> the freedom of those hackers who want to go their own way. They can
> always build their own activities from whatever tools they choose. The
> whole point of a framework is to help people get started quickly but it
> doesn't constrain anyone.
>
> This concludes part I. Here are some tantalizing morsels from Part II
> of "How to Make Activity Designers Happy,"
>
>
> - Where it's at: HTML, CSS, Javascript, and *gasp* Flash
> - Nepal's Content Development Experience
> - Aren't Kids going to create all learning activities so we don't
> have to?
>
>
>
> Bryan Berry is the Technology Director of href="http://www.olenepal.org">OLE Nepal and deadbeat co-editor of
> OLPCNews.com. Christopher Marin contributed his knowledge about all
> things web to this article
>
>
>
> In part 1, I talked about the paradoxical
> nature of open-source communities in developing countries, flaws in
> the current default activity development framework, and the urgent
> need for a new framework that makes activity designers happy.
>
> By happy, I mean that the framework rewards their efforts almost
> immediately (roughly 15 minutes of effort) and it lets them focus on
> presentation and gameplay rather than infrastructure. Last time I
> offered some vague ideas how this framework might function. This time
> I will provide more details how this framework could work and why.
>
> Let's Ride The Internet Wave
>
> The Internet is the 300-pound gorilla in the software-engineering room
> it will eat virtually everything, including your favorite desktop GUI
> framework. All of the IDE's bend over backwards to support coding of
> webapps, whether it is emacs, eclipse, or even vim. The software
> industry is making huge investments into web technologies that support
> the triumvirate of HTML/CSS/Javascript, witness Google's investment in
> V8 javascript compiler and
> Apple's investment in href="http://en.wikipedia.org/wiki/WebKit">Webkit. I speculate
> that there are many, many more developers working on GUI toolkits for
> the web browser- such as JQuery, Prototype, Script.aculo.us-than for
> GNOME or KDE desktop frameworks.
>
> The web will keep innovating at a breakneck pace. We need to ride that
> wave of innovation.
>
> In the early days of OLPC, we all had a lot of grandiose and
> impractical ideas. The educational systems of developing countries
> would change overnight into constructionist hotbeds. Kids would build
> their own activities, eliminating the need for large investments in
> content development. A million PyGTK apps with built-in collaboration
> and "View-Source" key would spontaneously bloom . . . Well, we're
> older and wiser now. School systems anywhere are not blank slates that
> we can redraw from scratch using cheap laptops and Etoys. Similarly,
> we cannot expect thousands of developers to flock to a framework
> (PyGTK) that is not commercially popular.
>
> Developing Country Developer Economics
>
> As I wrote in Part I, the economics of open-source in developing
> countries is quite different than that in the developed
> world. Developers there have ample enthusiasm for open-source but much
> less time to contribute.
>
> We need to lower the barrier of entry significantly in order to use
> their talents. In fact, we need to entice non-programmers such as
> graphic designers. In my limited experience, graphic designers are
> much better at designing learning activities than programmers. They
> better appreciate aesthetics and visual story-telling.
>
> Web designers layout their work using CSS and (X)HTML. They implement
> user interaction and animations using Javascript. They design their
> work using Photoshop, GIMP, Adobe Illustrator, and sometimes
> Eclipse. They know the features and dark areas of the Firefox web
> browser. Sugar infrastructure developers, these people are your
> customers. We need KARMA to enable them to quickly buidl activities
> for the XO without having to learn a whole new skillset. From a
> programmatic point of view, Browse needs to behave as much as possible
> like Firefox. Any discrepancy will distract activity designers from
> the more rewarding parts of activity development.
>
> Building Good KARMA
>
> Before we get too far, let's give this new activity framework a name
> so I can save us all a lot of excess verbiage. I call it KARMA,
> because the word is loosely-related to Nepal, my current residence,
> and I like to think creating open-source learning activities gives an
> individual good karma. Coincidentally, it is also the first two
> syllables of Rabi Karmacharya's last name--an individual put a ton of
> hard work and personal sacrifice into the OLPC project in Nepal.
>
> Well, I haven't actually made up my mind what the core technologies of
> KARMA
> should be. I need your help to work it out. Before I get into the
> technologies, here are my priorities. 1) These tools maximize
> programmer productivity and 2) are open-soure. Priority #1 is much
> more important than #2. 100% purely open-source activities that don't
> exist don't help kids learn. The current pygtk framework is purely
> open-source but you have to become a unix programmer to use it. As I
> noted in Part I, the vast, vast majority of programmers in the
> developing world are web developers and a successful activity
> framework will allow them to re-use their existing skills and tools.
>
> I have settled on HTML and CSS for the presentation but it is tougher
> to decide on the scripting toolset and on persistent data
> storage. Flash handles animations really well and it is easy to
> integrate audio into the animations. Adobe sells some really nice
> WYSIWYG tools for editing animation and adding audio. A lot of
> developers know flash so there is a large pool of talent we can draw
> from. Did I forget to mention that Flash is proprietary?
>
> The closed-source issue not withstanding, Flash is the tool to
> use. Some may be upset that Flash doesn't lend itself to "View Source"
> functionality but learning programming is not the sum total of
> education. Kids can do all the programming they ever want to w/ the
> excellent Etoys and Scratch. Sorry to sound like a broken record, but
> Afghani kids won't be able to view the source of Pashto grammar
> activities that don't exist, let alone interactively learn the rules
> of Pashto grammar.
>
> Flash Ain't Open-Source
>
> Flash is not _as_ closed-source as other software applications like
> Windows. The Adobe has published the specification for their SWF file
> format and the ActionScript 3.0 compiler is open-source. However, the
> Adobe's development tools such as Adobe Animator, Illustrator,
> Photoshop, etc. are not open-source. Nor is Adobe's flash player
> plugin. There is the open-source Gnash player but it does not fully
> support Actionscript 3 or Flash version 9. Rob Savoye and his team at
> Open Media Now do a great job but they seriously lack resources. Note:
> Rob
> Savoye, please correct my egregious errors.
>
> Javascript Isn't Ready
>
> I put in a good number of research hours into this article. I really,
> really wanted to find a pure javascript framework that could compete
> with Flash. I couldn't find one that does. There are libraries like
> DOJO, JQuery, and Processing.js
> http://ejohn.org/blog/processingjs/. Unfortunately, there aren't any
> IDE's that provide WYSIWYG animation editing for these tools. Every
> try to edit photos from a text editor? It's painful, really
> painful. So while real programmers use emacs (or vi, joe, sam, etc.),
> designers use WYSIWYG GUI's.
>
> Sadly, Javascript can't use the Graphics Processing Unit like Flash
> can. Ouch, it's a pain in the ass to couple animations with sound
> files. Based on my research so far, pure javascript won't be able to
> compete with Flash for at least the next several years. Please prove
> me wrong. Please post a comment to this article linking to some
> Javascript wonderfulness that pulls even with Flash.
>
>
> I will continue with the assumption that KARMA will use flash. I will
> happily revise this article ex post facto if someone in cyberspace
> points me to a pure javascript solution that makes activity designers
> happy.
>
> Building Momentum for Gnash
>
> I believe that the best way to increase interest in fully open-source
> flash is to make Flash more central in the evolving open-source
> education stack rather than minimizing its role. We definitely cannot
> wait for Gnash to fully support every feature of the proprietary flash
> before we begin using it. Open-Source starts when a single developer
> "scratches an itch" as the proverb goes. It follows then that the best
> way to bring Gnash up to speed we need to create a nasty, festering
> sore that irritates the open-source community into action.
>
> Moving the Conversation Forward
>
> Many people will likely hate my promotion of Flash for learning
> activities. It's OK if you hate me and Flash. I do hope you recognize
> that we need a more developer-centric activity framework that uses web
> technologies.
>
> I have a lot more to write about Nepal's experiences developing
> learning activities and my ideas on Convention over Configuration in
> sugar activities. I will save those for another day.
>
>
> --
> Bryan W. Berry
> Technology Director
> OLE Nepal, http://www.olenepal.org
>
> _______________________________________________
> IAEP -- It's An Education Project (not a laptop project!)
> IAEP at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>
From bryan at olenepal.org Fri Jan 2 13:57:03 2009
From: bryan at olenepal.org (Bryan Berry)
Date: Fri, 02 Jan 2009 10:57:03 -0800
Subject: [Sugar-devel] [IAEP] How to Make Activity Designers Happy ,
Parts I and II
In-Reply-To: <7087c32a0901020930g3a529a23tbc789fb4bddf8574@mail.gmail.com>
References: <1230861040.17108.4.camel__8009.18864920295$1230861178$gmane$org@hitman>
<1230874359.17108.16.camel@hitman>
<1230912293.17108.41.camel@hitman>
<7087c32a0901020930g3a529a23tbc789fb4bddf8574@mail.gmail.com>
Message-ID: <1230922623.17108.44.camel@hitman>
On Fri, 2009-01-02 at 12:30 -0500, Wade Brainerd wrote:
>
> I think Bryan's idea is wonderfully practical. What's more, it sounds
> easy to achieve. You just need a 'swf-activity' launcher, and a
> script to sugarize .SWF files into .xo bundles which launch as
> fullscreen activities.
that's a great idea
> Building it around Browse is probably a bad idea (re: the .xol
> suggestion). What's the point of loading up Firefox just to play a
> SWF file?
I think Firefox has some advantages because it is the environment that
many web developers are familiar. It does add a lot of overhead though.
Currently we use Firefox3 to launch Nepal's new flash-based activities.
It has some problems
> There is still a place for PyGTK. If you want the "real" Sugar, e.g.
> collaboration, Journal interaction, the visual theme, etc. stick with
> PyGTK. If you want a simple Pashto grammar activity and have Flash
> programmers at your disposal, use Flash.
There is very much a place for pygtk. It is excellent for developers who
have more time on their hands and/or previous experience w/ pygtk. It
also provides you w/ better access to the XO hardware.
> -Wade
--
Bryan W. Berry
Technology Director
OLE Nepal, http://www.olenepal.org
From bryan at olenepal.org Fri Jan 2 14:17:07 2009
From: bryan at olenepal.org (Bryan Berry)
Date: Fri, 02 Jan 2009 11:17:07 -0800
Subject: [Sugar-devel] How to Make Activity Designers Happy ,
Parts I and II
In-Reply-To:
References: <1230861040.17108.4.camel__8009.18864920295$1230861178$gmane$org@hitman>
<1230874359.17108.16.camel@hitman>
<1230912293.17108.41.camel@hitman>
Message-ID: <1230923827.17108.65.camel@hitman>
On Fri, 2009-01-02 at 12:46 -0500, Walter Bender wrote:
> Bryan, I appreciate you raising this discussion thread. Unequivocally,
> We need to make it easier for everyone to contribute.
Thanks for your support!
> In regard to your essay, I think it is important in this discussion to
> make a clearer distinction between (1) the constraints on FLOSS
> development in the developing world (i.e., the need to get paid); (2)
> the tools one uses for that work (e.g., Flash vs Javascript/HTML vs
> Python); (3) the role that "educational content" providers might play
> in development (i.e., who are they and are they primarily writing
> software?); and (4) the pedagogy we are espousing (e.g., is
> constructionism the only game in town?).
>
> 1. While others have also observed that there is a need for profit in
> the developing world for software developers, this by no means
> disqualifies FLOSS development. It just means that the profit comes
> not from selling a license to a closed package, but getting paid, for
> example, by providing a service. There is not necessarily new money to
> be had and it will take time to redirect money in the system that is
> directed towards FLOSS developers. But that doesn't suggest that FLOSS
> should be abandoned. It is clear that at least for education (and
> voting), FLOSS is *the* right way.
I am suggesting Flash because FLOSS should not exclusively be the domain
of linux programmers.
Certainly, some programmers need to get paid but the point of my article
is that there are many developers in the developing world more than
happy to volunteer their time. Unfortunately, that time is constrained
and we need to empower them to use tools they are familiar w/ rather
than forcing them to become linux programmers.
I agree that FLOSS is absolutely the right way. However that doesn't
mean that XYZ developer uses Photoshop and Adobe Illustrator to create a
flash activity, their resulting work can't be open-source too.
> 2. Low-cost/moderately powered hardware platforms do present some
> constraints on what tools and solutions are suitable. Other
> constraints include what skills are locally available and what rising
> tides should be exploited. HTML/Javascript is probably the
> lowest-hanging fruit, although Javascript performance on the OLPC-XO-1
> hardware can be sluggish. But not as sluggish as Flash. It may be
> worth someone making a concerted effort to help Rob fine-tune Gnash
> (only Adobe can tune Flash) for the XO. The Sugar team will continue
> to try to lower the barriers to developing native Sugar Activities and
> putting Sugar wrappers around existing applications, be they written
> in Javascript (e.g., SocialCalc) or Python or any other environment.
> The foci are to provide ready access to the Journal and the
> collaboration mechanisms ("convention over configuration"). (Wade's
> note that arrived while I was composing this one is an example of what
> we can do as a community to help individual development efforts.
I find that Flash runs plenty fast using the proprietary flash player.
It is only slightly slower than a pygtk app. Unfortunately, flash is
quite sluggish using Gnash by a factor of 2 or 3 if it runs at all.
I hope that my article's appearance in olpcnews.com will spur more
developers to assist Rob on gnash.
There is nothing in Adobe's Flash player licensing that restricts me
from installing it Nepal's default XO image. Their licensing does
restrict me from posting a software image that include the flash plugin
on the Internet.
> 3. While I am thrilled that some classroom teachers are beginning to
> participate directly in the software development process (e.g.,
> TurtleArt and Labyrinth), I am convinced that their major contribution
> will be more at the level of integration. There is a wonderful
> "curriculum" developed in Peru on community publishing that leverages
> Record, Write, Browse, and Chat. It didn't involve any Javascript or
> Flash, just thoughtful synthesis of the available tools. There are
> holes in our repertoire that preclude certain types of curriculum
> development: I am working on some presentation/portfolio tools, for
> example. What other holes need filling? And I am curious as to your
> experience working with teachers within the Etoys framework. Was that
> too difficult for them to master? How could we make it more
> accessible? And what are the roadblocks to developing web content for
> Sugar and/or OLPC-XOs?
It takes a long time to train teachers to use Etoys who have never used
a computer before. Etoys _requires_ mastery of the touchpad and that was
more than we could teach in 2 weeks of training. Dragging and dropping
is a non-trivial skill.
I think we can train teachers familiar w/ computers how to use Etoys.
Unfortunately, 95% of the teachers we deal and will deal w/ are not very
familiar w/ computers.
This is one of the major differences b/w Nepal's deployments and those
of more developed countries like Uruguay.
> 4. Constructionism is not the only way. Our strategy at Sugar Labs is
> to make a platform that encourages more constructionism in the
> learning process, but that it would be a matter of lowering the
> barriers to entry, not closing doors to other approaches. To repeat a
> well-wore analogy: you can read a book in either PDF or Wiki format,
> but the chances that the reader will make annotations, add to a
> discussion, and even add to the content are all much greater with a
> Wiki because it has the proper affordances for such interventions.
> Providing such affordances to the learning experience might be
> motivated by a specific pedagogy, but it does not preclude other
> approaches.
>
> -walter
I love constructionism but too often we focus exclusively high-level
math and science and not "foundational" skills or art, literature,
grammar, health, etc. By foundational skills I mean basic literacy and
numeracy. Kids can't create an Etoys game until they can count properly.
They can't read the dialogues until they understand phonics properly.
Some vocabulary has to be memorized and kids have to be able to add #'s
quickly in their head. When was the last time you reached for a
calculator to compute 5 + 5? If you did, you would work much more
slowly.
I find that Sugar contributors from developed countries are focused more
on high-level thinking because that is a deficiency in their local
school systems. Their kids can do basic math and _usually_ know basic
grammar. Poorer countries are focused on basic numeracy and literacy.
You can't program until you can add and read.
Countries like Peru and Brazil have schools where kids are ready to
focus on high level problems. They also probably have schools struggling
to impart basic literacy and numeracy.
--
Bryan W. Berry
Technology Director
OLE Nepal, http://www.olenepal.org
From bryan at olenepal.org Fri Jan 2 14:30:46 2009
From: bryan at olenepal.org (Bryan Berry)
Date: Fri, 02 Jan 2009 11:30:46 -0800
Subject: [Sugar-devel] web-based activities (was Re: [IAEP] How to Make
Activity Designers Happy , Parts I and II)
In-Reply-To: <242851610901021018r4c84d249r8b348dc126c4bbe9@mail.gmail.com>
References: <242851610901021018r4c84d249r8b348dc126c4bbe9@mail.gmail.com>
Message-ID: <1230924646.17108.76.camel@hitman>
On Fri, 2009-01-02 at 19:18 +0100, Tomeu Vizoso wrote:
> Hi,
>
> without needing to get into what is better for our deployments, I do
> see value in making easier to make Sugar activities using technologies
> such as HTML, CSS, etc
> Bryan, can we get into a more detailed view on what it would take
> ideally to create a new activity using such activities? Which would be
> the steps that an experienced web designer would need to take in order
> to create a Sugar activity?
Presently, we do the following to run flash activities on the XO
1) download the Firefox3.xo bundle
2) change the activity.info file
3) change some of the file and directory names to reference
EPaathActivity instead of FirefoxActivity
4) copy the swf (flash) files to ./activity/Activity/Activities (I know
it's ugly
5) change the firefoxactivity.py
ff = [ './firefox' ]
to
ff = [ './firefox', './activity/Activity/Activities/OurSWF.htm']
> I'm sure that someone with basic knowledge of python could create some
> tools that make it much more easier than it is today. Also have some
> ideas about how those activities could interact with the journal and
> other Sugar features.
>
> Thanks,
>
> Tomeu
Again, this requires people to learn python, a whole new language that
they don't necessarily use at work. We need to enable developers to be
very productive in just 2-3 hours per week. For them to be productive
they need to be using tools they are already familiar w/.
Python is a tool popular among sysadmins and hackers. It is great tool.
But folks who develop web UIs use css, html, javascript, and flash. I
highly doubt that will change in the near or distant future. These are
people we need to recruit as activity designers.
> On Fri, Jan 2, 2009 at 02:50, Bryan Berry wrote:
> > This is a draft of a multi-part article I plan to post to OLPC News.
> >
> > It is very long but I would very much appreciate your opinions and
> > feedback. Your input will make it a better article once published.
> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >
> > This OLPC project seems to be going pretty well as of late December
> > 2008. G1G1 v2 is well underway, there are a number of successful pilots
> > going on, and a number of larger-scale pilots will come online this
> > spring and coming summer.
> >
> > Still, there is a big gaping whole in the middle of our little education
> > project. There just aren't enough activities. Mind you, we have some
> > seriously awesome activities such as Etoys, Scratch, TamTam, and others.
> > We have tremendous depth but very limited breadth.
> >
> > By breadth, I mean interactive activities for language, history,
> > geology, health, etc. In order to expand the range of activities, we
> > need to recruit a lot more activity developers and make it dead-simple
> > for them to contribute.
> >
> > But Which Developers?
> >
> > Let's think about who we want to recruit. We're talking about breadth
> > here so we need experts on Nepali grammar, Pashto vocabulary, Philippine
> > history, and Andean geography. The good news is that there are
> > technically-oriented people out there that know these things and want to
> > help.
> >
> > We already have a hardcore team of dedicated hackers. We need them for
> > the work that hackers excel at: building infrastructure, testing the
> > limits of new systems. But now we need a different class of developer,
> > those that are focused on the presentation, game play and not system
> > internals.
> >
> > Based on these characteristics, let's call these people
> > designers. The good news is that there are lots of
> > designers-particularly in developing countries-that want to contribute
> > to OLPC. The bad news is that they don't know python. or GTK+. They may
> > not even be familiar with linux. They do know HTML, CSS, Javascript, and
> > Adobe Flash. Allow me to explain.
> >
> > Due to rise of the Internet and related boom in outsourcing, the vast,
> > vast majority of programmers in developing countries are web developers
> > (according to my own grossly unscientific survey). The rise of the
> > Internet has also led a lot of talented graphic designers in developing
> > and developed countries to learn web technologies. I even
> > wager that CSS/HTML/Javascript will become the de facto GUI technologies
> > in a few years time. > href="http://en.wikipedia.org/wiki/Pygtk">PyGTK won't take over the
> > world nor will VB.net.
> >
> > The popular term for this triumvirate of technologies is > href="http://en.wikipedia.org/wiki/AJAX">AJAX, with the difference
> > that AJAX applications typically require communication with a remote
> > server. I propose using web technologies for completely offline
> > activities. Adobe's Flash is basically a variant of AJAX that uses
> > dialects of Javascript ( > href="http://en.wikipedia.org/wiki/Actionscript">Actionscript) and
> > XML (MXML).
> >
> > Very few programmers in the developed world get paid to write desktop
> > linux apps. Still, open-source developers find learn and build pygtk,
> > mono, and KDE apps in their free-time. Developers in the developing
> > world are extremely enthusiastic about FOSS but not nearly as prolific
> > in creating open-source software due to a phenomenon I
> > call the "FOSS-Nepal Paradox."
> >
> > The > href="http://wiki.fossnepal.org/index.php?title=The_FOSS_Nepal_Community">FOSS Nepal community has won the award for best celebration of Software Freedom day for two years in a running. Despite all this enthusiasm the FOSS Nepal community is not very prolific in producing open-source code. The reason for this is that Nepal is not a wealthy country and that Open-Source is expensive to produce.
> >
> > Open-Source is Expensive
> >
> > Open-source software voraciously consumes a resource even more valuable
> > than hard cash, programmer time. Linus Torvalds could afford to spend
> > some of the most productive years of his life working without immediate
> > financial benefit. He could slack off in his classes without fear of
> > unemployment upon graduation. I doubt his parents were counting on him
> > to support them financially once he got a job.
> >
> > Most talented Nepali programmers I know do not have those luxuries. They
> > are under a lot of pressure to support their parents and extended
> > families, financially and otherwise. So Nepalis, Bangladeshis, Peruanos,
> > etc. certainly have the passion and ability to contribute to open-source
> > but their free time is significantly more limited.
> >
> > This doesn't mean that we should rely on developers from rich countries.
> > We simply need to radically lower the amount of time required to create
> > learning activities. I believe that many, many developers in the
> > developing world can contribute 3-5 hours per week. To make those few
> > hours productive we need to rework the default activity framework.
> >
> > >From what I can tell, the primary design goals of the default PyGTK
> > activity
> > framework are as follows:
> >
> > - Give the programmer maximum flexibility
- Fully exploit
> > the XO's hardware features
- Mesh nicely with Sugar
> >
> > These three goals are laudable and their hacker roots are obvious. The
> > problem is that these goals maximize the technology's potential rather
> > than programmer productivity. We need reach beyond the vi/emacs crowd
> > (Note: I wrote this article using emacs) to thos folks that the masters
> > of Photoshop, Adobe Illustrator, Eclipse, and GIMP.
> >
> > I propose a new set of design goals:
> >
> >
> > - Allow activity designers to quickly build activities utilizing
> > widely-used tools.
> > - Quickly reward effort with working behavior
> > - Mesh nicely with the Sugar UI
> >
> >
> > It's OK to be Opinionated
> >
> > We need an opinionated activity framework that makes infrastructure
> > choices for the designer so that she can focus presentation and
> > gameplay. Some may recognize this as the principle of > href="http://en.wikipedia.org/wiki/Convention_over_Configuration">Convention Over Configuration, a principle that two of the most popular web frameworks, Django and RubyOnRails, adhere to. Now a lot of geeks don't like Convention over Configuration--perl hackers especially--but they sure do allow you to create nice applications very quickly.
> >
> > Establishing an "opinionated" activity framework will in no way limit
> > the freedom of those hackers who want to go their own way. They can
> > always build their own activities from whatever tools they choose. The
> > whole point of a framework is to help people get started quickly but it
> > doesn't constrain anyone.
> >
> > This concludes part I. Here are some tantalizing morsels from Part II
> > of "How to Make Activity Designers Happy,"
> >
> >
> > - Where it's at: HTML, CSS, Javascript, and *gasp* Flash
> > - Nepal's Content Development Experience
> > - Aren't Kids going to create all learning activities so we don't
> > have to?
> >
> >
> >
> > Bryan Berry is the Technology Director of > href="http://www.olenepal.org">OLE Nepal and deadbeat co-editor of
> > OLPCNews.com. Christopher Marin contributed his knowledge about all
> > things web to this article
> >
> >
> >
> > In part 1, I talked about the paradoxical
> > nature of open-source communities in developing countries, flaws in
> > the current default activity development framework, and the urgent
> > need for a new framework that makes activity designers happy.
> >
> > By happy, I mean that the framework rewards their efforts almost
> > immediately (roughly 15 minutes of effort) and it lets them focus on
> > presentation and gameplay rather than infrastructure. Last time I
> > offered some vague ideas how this framework might function. This time
> > I will provide more details how this framework could work and why.
> >
> > Let's Ride The Internet Wave
> >
> > The Internet is the 300-pound gorilla in the software-engineering room
> > it will eat virtually everything, including your favorite desktop GUI
> > framework. All of the IDE's bend over backwards to support coding of
> > webapps, whether it is emacs, eclipse, or even vim. The software
> > industry is making huge investments into web technologies that support
> > the triumvirate of HTML/CSS/Javascript, witness Google's investment in
> > V8 javascript compiler and
> > Apple's investment in > href="http://en.wikipedia.org/wiki/WebKit">Webkit. I speculate
> > that there are many, many more developers working on GUI toolkits for
> > the web browser- such as JQuery, Prototype, Script.aculo.us-than for
> > GNOME or KDE desktop frameworks.
> >
> > The web will keep innovating at a breakneck pace. We need to ride that
> > wave of innovation.
> >
> > In the early days of OLPC, we all had a lot of grandiose and
> > impractical ideas. The educational systems of developing countries
> > would change overnight into constructionist hotbeds. Kids would build
> > their own activities, eliminating the need for large investments in
> > content development. A million PyGTK apps with built-in collaboration
> > and "View-Source" key would spontaneously bloom . . . Well, we're
> > older and wiser now. School systems anywhere are not blank slates that
> > we can redraw from scratch using cheap laptops and Etoys. Similarly,
> > we cannot expect thousands of developers to flock to a framework
> > (PyGTK) that is not commercially popular.
> >
> > Developing Country Developer Economics
> >
> > As I wrote in Part I, the economics of open-source in developing
> > countries is quite different than that in the developed
> > world. Developers there have ample enthusiasm for open-source but much
> > less time to contribute.
> >
> > We need to lower the barrier of entry significantly in order to use
> > their talents. In fact, we need to entice non-programmers such as
> > graphic designers. In my limited experience, graphic designers are
> > much better at designing learning activities than programmers. They
> > better appreciate aesthetics and visual story-telling.
> >
> > Web designers layout their work using CSS and (X)HTML. They implement
> > user interaction and animations using Javascript. They design their
> > work using Photoshop, GIMP, Adobe Illustrator, and sometimes
> > Eclipse. They know the features and dark areas of the Firefox web
> > browser. Sugar infrastructure developers, these people are your
> > customers. We need KARMA to enable them to quickly buidl activities
> > for the XO without having to learn a whole new skillset. From a
> > programmatic point of view, Browse needs to behave as much as possible
> > like Firefox. Any discrepancy will distract activity designers from
> > the more rewarding parts of activity development.
> >
> > Building Good KARMA
> >
> > Before we get too far, let's give this new activity framework a name
> > so I can save us all a lot of excess verbiage. I call it KARMA,
> > because the word is loosely-related to Nepal, my current residence,
> > and I like to think creating open-source learning activities gives an
> > individual good karma. Coincidentally, it is also the first two
> > syllables of Rabi Karmacharya's last name--an individual put a ton of
> > hard work and personal sacrifice into the OLPC project in Nepal.
> >
> > Well, I haven't actually made up my mind what the core technologies of
> > KARMA
> > should be. I need your help to work it out. Before I get into the
> > technologies, here are my priorities. 1) These tools maximize
> > programmer productivity and 2) are open-soure. Priority #1 is much
> > more important than #2. 100% purely open-source activities that don't
> > exist don't help kids learn. The current pygtk framework is purely
> > open-source but you have to become a unix programmer to use it. As I
> > noted in Part I, the vast, vast majority of programmers in the
> > developing world are web developers and a successful activity
> > framework will allow them to re-use their existing skills and tools.
> >
> > I have settled on HTML and CSS for the presentation but it is tougher
> > to decide on the scripting toolset and on persistent data
> > storage. Flash handles animations really well and it is easy to
> > integrate audio into the animations. Adobe sells some really nice
> > WYSIWYG tools for editing animation and adding audio. A lot of
> > developers know flash so there is a large pool of talent we can draw
> > from. Did I forget to mention that Flash is proprietary?
> >
> > The closed-source issue not withstanding, Flash is the tool to
> > use. Some may be upset that Flash doesn't lend itself to "View Source"
> > functionality but learning programming is not the sum total of
> > education. Kids can do all the programming they ever want to w/ the
> > excellent Etoys and Scratch. Sorry to sound like a broken record, but
> > Afghani kids won't be able to view the source of Pashto grammar
> > activities that don't exist, let alone interactively learn the rules
> > of Pashto grammar.
> >
> > Flash Ain't Open-Source
> >
> > Flash is not _as_ closed-source as other software applications like
> > Windows. The Adobe has published the specification for their SWF file
> > format and the ActionScript 3.0 compiler is open-source. However, the
> > Adobe's development tools such as Adobe Animator, Illustrator,
> > Photoshop, etc. are not open-source. Nor is Adobe's flash player
> > plugin. There is the open-source Gnash player but it does not fully
> > support Actionscript 3 or Flash version 9. Rob Savoye and his team at
> > Open Media Now do a great job but they seriously lack resources. Note:
> > Rob
> > Savoye, please correct my egregious errors.
> >
> > Javascript Isn't Ready
> >
> > I put in a good number of research hours into this article. I really,
> > really wanted to find a pure javascript framework that could compete
> > with Flash. I couldn't find one that does. There are libraries like
> > DOJO, JQuery, and Processing.js
> > http://ejohn.org/blog/processingjs/. Unfortunately, there aren't any
> > IDE's that provide WYSIWYG animation editing for these tools. Every
> > try to edit photos from a text editor? It's painful, really
> > painful. So while real programmers use emacs (or vi, joe, sam, etc.),
> > designers use WYSIWYG GUI's.
> >
> > Sadly, Javascript can't use the Graphics Processing Unit like Flash
> > can. Ouch, it's a pain in the ass to couple animations with sound
> > files. Based on my research so far, pure javascript won't be able to
> > compete with Flash for at least the next several years. Please prove
> > me wrong. Please post a comment to this article linking to some
> > Javascript wonderfulness that pulls even with Flash.
> >
> >
> > I will continue with the assumption that KARMA will use flash. I will
> > happily revise this article ex post facto if someone in cyberspace
> > points me to a pure javascript solution that makes activity designers
> > happy.
> >
> > Building Momentum for Gnash
> >
> > I believe that the best way to increase interest in fully open-source
> > flash is to make Flash more central in the evolving open-source
> > education stack rather than minimizing its role. We definitely cannot
> > wait for Gnash to fully support every feature of the proprietary flash
> > before we begin using it. Open-Source starts when a single developer
> > "scratches an itch" as the proverb goes. It follows then that the best
> > way to bring Gnash up to speed we need to create a nasty, festering
> > sore that irritates the open-source community into action.
> >
> > Moving the Conversation Forward
> >
> > Many people will likely hate my promotion of Flash for learning
> > activities. It's OK if you hate me and Flash. I do hope you recognize
> > that we need a more developer-centric activity framework that uses web
> > technologies.
> >
> > I have a lot more to write about Nepal's experiences developing
> > learning activities and my ideas on Convention over Configuration in
> > sugar activities. I will save those for another day.
> >
> >
> > --
> > Bryan W. Berry
> > Technology Director
> > OLE Nepal, http://www.olenepal.org
> >
> > _______________________________________________
> > IAEP -- It's An Education Project (not a laptop project!)
> > IAEP at lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/iaep
> >
--
Bryan W. Berry
Technology Director
OLE Nepal, http://www.olenepal.org
From wadetb at gmail.com Fri Jan 2 14:32:30 2009
From: wadetb at gmail.com (Wade Brainerd)
Date: Fri, 2 Jan 2009 14:32:30 -0500
Subject: [Sugar-devel] web-based activities (was Re: [IAEP] How to Make
Activity Designers Happy , Parts I and II)
In-Reply-To: <242851610901021018r4c84d249r8b348dc126c4bbe9@mail.gmail.com>
References: <242851610901021018r4c84d249r8b348dc126c4bbe9@mail.gmail.com>
Message-ID: <7087c32a0901021132s7423157av3ad1cfa4267b9326@mail.gmail.com>
The work we did for WikiBrowse (the WikipediaES and WikipediaEN) activities
would make a good starting point.
First of all the Browse code should be integrated into Sugar. This has been
discussed before, and makes sense since you guys are maintaining the Browse
activity anyway.
The Browse code would be provided as a base
sugar.activity.webactivity.WebActivity class. Currently, "web-based"
activities (not content bundles) need to manually find the path to the
Browse installation (assuming there is one!) and import its modules which
feels rather hacky.
The sugar.activity.webactivity module should also provide a WebServer
class. This class is a SimpleHTTPServer derivative which supports iterating
and finding and returning an unused local port to serve over. The server
would handle GET/POST requests to a special '/journal/' URL prefix,
allowing DHTML scripts access to the activity's Journal entry.
Finally, a web-activity launcher script should be created. This script
launches the Sugar Browse code and supports a variety of command line
options to control what parts of the Browse UI are enabled, and to set the
home page. It should be possible to launch a Browse instance with nothing
but the Activity toolbar for example.
These steps will allow for three (or more!) different variations on
"web-based" activities:
1) Static HTML and/or DHTML ala the existing .xol system. A collection of
.html, css and .js files can be bundled as a .xo file. The included
activity.info exec line calls web-activity with appropriate command line
options.
The advantage of this approach over .xol files is that the "web-based
activity" appears as a first class object in the Sugar UI with an
independent icon on the Home view. Further, since the
sugar.activity.webactivity.WebServer is used, DHTML code can read/write from
the activity's Journal entry.
2) Static HTML and/or DHTML with custom UI. In WikiBrowse, I subclassed
WebActivity and added a new Search toolbar, which searches the wiki DB and
retrieves a page of results. This is the same as variation 1, except
instead of calling "web-activity", a new Python activity class is derived
from sugar.activity.webactivity.WebActivity and modifies the UI in some way
- adding toolbars, etc.
3) Static HTML and/or DHTML with custom server. In WikiBrowse, a custom
webserver attaches to a local port and serves wiki pages. It decompresses
and formats wiki pages before serving them up as XHTML. So in this
variation, a simple Python WebServer class is derived from
sugar.activity.webactivity.WebServer and the appropriate page request
handing methods are added. The base WebServer class additionally handles
GET/POST request to access the Journal entry for the activity.
Doing this work would allow us to rewrite WikiBrowse in a much cleaner
fashion, and would allow a whole range of first class Web-based Sugar
activities.
Cheers,
Wade
On Fri, Jan 2, 2009 at 1:18 PM, Tomeu Vizoso wrote:
> Hi,
>
> without needing to get into what is better for our deployments, I do
> see value in making easier to make Sugar activities using technologies
> such as HTML, CSS, etc
>
> Bryan, can we get into a more detailed view on what it would take
> ideally to create a new activity using such activities? Which would be
> the steps that an experienced web designer would need to take in order
> to create a Sugar activity?
>
> I'm sure that someone with basic knowledge of python could create some
> tools that make it much more easier than it is today. Also have some
> ideas about how those activities could interact with the journal and
> other Sugar features.
>
> Thanks,
>
> Tomeu
>
> On Fri, Jan 2, 2009 at 02:50, Bryan Berry wrote:
> > This is a draft of a multi-part article I plan to post to OLPC News.
> >
> > It is very long but I would very much appreciate your opinions and
> > feedback. Your input will make it a better article once published.
> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >
> > This OLPC project seems to be going pretty well as of late December
> > 2008. G1G1 v2 is well underway, there are a number of successful pilots
> > going on, and a number of larger-scale pilots will come online this
> > spring and coming summer.
> >
> > Still, there is a big gaping whole in the middle of our little education
> > project. There just aren't enough activities. Mind you, we have some
> > seriously awesome activities such as Etoys, Scratch, TamTam, and others.
> > We have tremendous depth but very limited breadth.
> >
> > By breadth, I mean interactive activities for language, history,
> > geology, health, etc. In order to expand the range of activities, we
> > need to recruit a lot more activity developers and make it dead-simple
> > for them to contribute.
> >
> > But Which Developers?
> >
> > Let's think about who we want to recruit. We're talking about breadth
> > here so we need experts on Nepali grammar, Pashto vocabulary, Philippine
> > history, and Andean geography. The good news is that there are
> > technically-oriented people out there that know these things and want to
> > help.
> >
> > We already have a hardcore team of dedicated hackers. We need them for
> > the work that hackers excel at: building infrastructure, testing the
> > limits of new systems. But now we need a different class of developer,
> > those that are focused on the presentation, game play and not system
> > internals.
> >
> > Based on these characteristics, let's call these people
> > designers. The good news is that there are lots of
> > designers-particularly in developing countries-that want to contribute
> > to OLPC. The bad news is that they don't know python. or GTK+. They may
> > not even be familiar with linux. They do know HTML, CSS, Javascript, and
> > Adobe Flash. Allow me to explain.
> >
> > Due to rise of the Internet and related boom in outsourcing, the vast,
> > vast majority of programmers in developing countries are web developers
> > (according to my own grossly unscientific survey). The rise of the
> > Internet has also led a lot of talented graphic designers in developing
> > and developed countries to learn web technologies. I even
> > wager that CSS/HTML/Javascript will become the de facto GUI technologies
> > in a few years time. > href="http://en.wikipedia.org/wiki/Pygtk">PyGTK won't take over the
> > world nor will VB.net.
> >
> > The popular term for this triumvirate of technologies is > href="http://en.wikipedia.org/wiki/AJAX">AJAX, with the difference
> > that AJAX applications typically require communication with a remote
> > server. I propose using web technologies for completely offline
> > activities. Adobe's Flash is basically a variant of AJAX that uses
> > dialects of Javascript ( > href="http://en.wikipedia.org/wiki/Actionscript">Actionscript) and
> > XML (MXML).
> >
> > Very few programmers in the developed world get paid to write desktop
> > linux apps. Still, open-source developers find learn and build pygtk,
> > mono, and KDE apps in their free-time. Developers in the developing
> > world are extremely enthusiastic about FOSS but not nearly as prolific
> > in creating open-source software due to a phenomenon I
> > call the "FOSS-Nepal Paradox."
> >
> > The > href="http://wiki.fossnepal.org/index.php?title=The_FOSS_Nepal_Community">FOSS
> Nepal community has won the award for best
> celebration of Software Freedom day for two years in a running. Despite all
> this enthusiasm the FOSS Nepal community is not very prolific in producing
> open-source code. The reason for this is that Nepal is not a wealthy country
> and that Open-Source is expensive to produce.
> >
> > Open-Source is Expensive
> >
> > Open-source software voraciously consumes a resource even more valuable
> > than hard cash, programmer time. Linus Torvalds could afford to spend
> > some of the most productive years of his life working without immediate
> > financial benefit. He could slack off in his classes without fear of
> > unemployment upon graduation. I doubt his parents were counting on him
> > to support them financially once he got a job.
> >
> > Most talented Nepali programmers I know do not have those luxuries. They
> > are under a lot of pressure to support their parents and extended
> > families, financially and otherwise. So Nepalis, Bangladeshis, Peruanos,
> > etc. certainly have the passion and ability to contribute to open-source
> > but their free time is significantly more limited.
> >
> > This doesn't mean that we should rely on developers from rich countries.
> > We simply need to radically lower the amount of time required to create
> > learning activities. I believe that many, many developers in the
> > developing world can contribute 3-5 hours per week. To make those few
> > hours productive we need to rework the default activity framework.
> >
> > >From what I can tell, the primary design goals of the default PyGTK
> > activity
> > framework are as follows:
> >
> > - Give the programmer maximum flexibility
- Fully exploit
> > the XO's hardware features
- Mesh nicely with Sugar
> >
> > These three goals are laudable and their hacker roots are obvious. The
> > problem is that these goals maximize the technology's potential rather
> > than programmer productivity. We need reach beyond the vi/emacs crowd
> > (Note: I wrote this article using emacs) to thos folks that the masters
> > of Photoshop, Adobe Illustrator, Eclipse, and GIMP.
> >
> > I propose a new set of design goals:
> >
> >
> > - Allow activity designers to quickly build activities utilizing
> > widely-used tools.
> > - Quickly reward effort with working behavior
> > - Mesh nicely with the Sugar UI
> >
> >
> > It's OK to be Opinionated
> >
> > We need an opinionated activity framework that makes infrastructure
> > choices for the designer so that she can focus presentation and
> > gameplay. Some may recognize this as the principle of > href="http://en.wikipedia.org/wiki/Convention_over_Configuration">Convention
> Over Configuration, a principle that two of the most popular web
> frameworks, Django and RubyOnRails, adhere to. Now a lot of geeks don't like
> Convention over Configuration--perl hackers especially--but they sure do
> allow you to create nice applications very quickly.
> >
> > Establishing an "opinionated" activity framework will in no way limit
> > the freedom of those hackers who want to go their own way. They can
> > always build their own activities from whatever tools they choose. The
> > whole point of a framework is to help people get started quickly but it
> > doesn't constrain anyone.
> >
> > This concludes part I. Here are some tantalizing morsels from Part II
> > of "How to Make Activity Designers Happy,"
> >
> >
> > - Where it's at: HTML, CSS, Javascript, and *gasp* Flash
> > - Nepal's Content Development Experience
> > - Aren't Kids going to create all learning activities so we
> don't
> > have to?
> >
> >
> >
> > Bryan Berry is the Technology Director of > href="http://www.olenepal.org">OLE Nepal and deadbeat co-editor of
> > OLPCNews.com. Christopher Marin contributed his knowledge about all
> > things web to this article
> >
> >
> >
> > In part 1, I talked about the paradoxical
> > nature of open-source communities in developing countries, flaws in
> > the current default activity development framework, and the urgent
> > need for a new framework that makes activity designers happy.
> >
> > By happy, I mean that the framework rewards their efforts almost
> > immediately (roughly 15 minutes of effort) and it lets them focus on
> > presentation and gameplay rather than infrastructure. Last time I
> > offered some vague ideas how this framework might function. This time
> > I will provide more details how this framework could work and why.
> >
> > Let's Ride The Internet Wave
> >
> > The Internet is the 300-pound gorilla in the software-engineering room
> > it will eat virtually everything, including your favorite desktop GUI
> > framework. All of the IDE's bend over backwards to support coding of
> > webapps, whether it is emacs, eclipse, or even vim. The software
> > industry is making huge investments into web technologies that support
> > the triumvirate of HTML/CSS/Javascript, witness Google's investment in
> > V8 javascript compiler and
> > Apple's investment in > href="http://en.wikipedia.org/wiki/WebKit">Webkit. I speculate
> > that there are many, many more developers working on GUI toolkits for
> > the web browser- such as JQuery, Prototype, Script.aculo.us-than for
> > GNOME or KDE desktop frameworks.
> >
> > The web will keep innovating at a breakneck pace. We need to ride that
> > wave of innovation.
> >
> > In the early days of OLPC, we all had a lot of grandiose and
> > impractical ideas. The educational systems of developing countries
> > would change overnight into constructionist hotbeds. Kids would build
> > their own activities, eliminating the need for large investments in
> > content development. A million PyGTK apps with built-in collaboration
> > and "View-Source" key would spontaneously bloom . . . Well, we're
> > older and wiser now. School systems anywhere are not blank slates that
> > we can redraw from scratch using cheap laptops and Etoys. Similarly,
> > we cannot expect thousands of developers to flock to a framework
> > (PyGTK) that is not commercially popular.
> >
> > Developing Country Developer Economics
> >
> > As I wrote in Part I, the economics of open-source in developing
> > countries is quite different than that in the developed
> > world. Developers there have ample enthusiasm for open-source but much
> > less time to contribute.
> >
> > We need to lower the barrier of entry significantly in order to use
> > their talents. In fact, we need to entice non-programmers such as
> > graphic designers. In my limited experience, graphic designers are
> > much better at designing learning activities than programmers. They
> > better appreciate aesthetics and visual story-telling.
> >
> > Web designers layout their work using CSS and (X)HTML. They implement
> > user interaction and animations using Javascript. They design their
> > work using Photoshop, GIMP, Adobe Illustrator, and sometimes
> > Eclipse. They know the features and dark areas of the Firefox web
> > browser. Sugar infrastructure developers, these people are your
> > customers. We need KARMA to enable them to quickly buidl activities
> > for the XO without having to learn a whole new skillset. From a
> > programmatic point of view, Browse needs to behave as much as possible
> > like Firefox. Any discrepancy will distract activity designers from
> > the more rewarding parts of activity development.
> >
> > Building Good KARMA
> >
> > Before we get too far, let's give this new activity framework a name
> > so I can save us all a lot of excess verbiage. I call it KARMA,
> > because the word is loosely-related to Nepal, my current residence,
> > and I like to think creating open-source learning activities gives an
> > individual good karma. Coincidentally, it is also the first two
> > syllables of Rabi Karmacharya's last name--an individual put a ton of
> > hard work and personal sacrifice into the OLPC project in Nepal.
> >
> > Well, I haven't actually made up my mind what the core technologies of
> > KARMA
> > should be. I need your help to work it out. Before I get into the
> > technologies, here are my priorities. 1) These tools maximize
> > programmer productivity and 2) are open-soure. Priority #1 is much
> > more important than #2. 100% purely open-source activities that don't
> > exist don't help kids learn. The current pygtk framework is purely
> > open-source but you have to become a unix programmer to use it. As I
> > noted in Part I, the vast, vast majority of programmers in the
> > developing world are web developers and a successful activity
> > framework will allow them to re-use their existing skills and tools.
> >
> > I have settled on HTML and CSS for the presentation but it is tougher
> > to decide on the scripting toolset and on persistent data
> > storage. Flash handles animations really well and it is easy to
> > integrate audio into the animations. Adobe sells some really nice
> > WYSIWYG tools for editing animation and adding audio. A lot of
> > developers know flash so there is a large pool of talent we can draw
> > from. Did I forget to mention that Flash is proprietary?
> >
> > The closed-source issue not withstanding, Flash is the tool to
> > use. Some may be upset that Flash doesn't lend itself to "View Source"
> > functionality but learning programming is not the sum total of
> > education. Kids can do all the programming they ever want to w/ the
> > excellent Etoys and Scratch. Sorry to sound like a broken record, but
> > Afghani kids won't be able to view the source of Pashto grammar
> > activities that don't exist, let alone interactively learn the rules
> > of Pashto grammar.
> >
> > Flash Ain't Open-Source
> >
> > Flash is not _as_ closed-source as other software applications like
> > Windows. The Adobe has published the specification for their SWF file
> > format and the ActionScript 3.0 compiler is open-source. However, the
> > Adobe's development tools such as Adobe Animator, Illustrator,
> > Photoshop, etc. are not open-source. Nor is Adobe's flash player
> > plugin. There is the open-source Gnash player but it does not fully
> > support Actionscript 3 or Flash version 9. Rob Savoye and his team at
> > Open Media Now do a great job but they seriously lack resources. Note:
> > Rob
> > Savoye, please correct my egregious errors.
> >
> > Javascript Isn't Ready
> >
> > I put in a good number of research hours into this article. I really,
> > really wanted to find a pure javascript framework that could compete
> > with Flash. I couldn't find one that does. There are libraries like
> > DOJO, JQuery, and Processing.js
> > http://ejohn.org/blog/processingjs/. Unfortunately, there aren't any
> > IDE's that provide WYSIWYG animation editing for these tools. Every
> > try to edit photos from a text editor? It's painful, really
> > painful. So while real programmers use emacs (or vi, joe, sam, etc.),
> > designers use WYSIWYG GUI's.
> >
> > Sadly, Javascript can't use the Graphics Processing Unit like Flash
> > can. Ouch, it's a pain in the ass to couple animations with sound
> > files. Based on my research so far, pure javascript won't be able to
> > compete with Flash for at least the next several years. Please prove
> > me wrong. Please post a comment to this article linking to some
> > Javascript wonderfulness that pulls even with Flash.
> >
> >
> > I will continue with the assumption that KARMA will use flash. I will
> > happily revise this article ex post facto if someone in cyberspace
> > points me to a pure javascript solution that makes activity designers
> > happy.
> >
> > Building Momentum for Gnash
> >
> > I believe that the best way to increase interest in fully open-source
> > flash is to make Flash more central in the evolving open-source
> > education stack rather than minimizing its role. We definitely cannot
> > wait for Gnash to fully support every feature of the proprietary flash
> > before we begin using it. Open-Source starts when a single developer
> > "scratches an itch" as the proverb goes. It follows then that the best
> > way to bring Gnash up to speed we need to create a nasty, festering
> > sore that irritates the open-source community into action.
> >
> > Moving the Conversation Forward
> >
> > Many people will likely hate my promotion of Flash for learning
> > activities. It's OK if you hate me and Flash. I do hope you recognize
> > that we need a more developer-centric activity framework that uses web
> > technologies.
> >
> > I have a lot more to write about Nepal's experiences developing
> > learning activities and my ideas on Convention over Configuration in
> > sugar activities. I will save those for another day.
> >
> >
> > --
> > Bryan W. Berry
> > Technology Director
> > OLE Nepal, http://www.olenepal.org
> >
> > _______________________________________________
> > IAEP -- It's An Education Project (not a laptop project!)
> > IAEP at lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/iaep
> >
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090102/54f25f22/attachment-0001.htm
From walter.bender at gmail.com Fri Jan 2 14:41:58 2009
From: walter.bender at gmail.com (Walter Bender)
Date: Fri, 2 Jan 2009 14:41:58 -0500
Subject: [Sugar-devel] How to Make Activity Designers Happy ,
Parts I and II
In-Reply-To: <1230923827.17108.65.camel@hitman>
References: <1230861040.17108.4.camel__8009.18864920295$1230861178$gmane$org@hitman>
<1230874359.17108.16.camel@hitman>
<1230912293.17108.41.camel@hitman>
<1230923827.17108.65.camel@hitman>
Message-ID:
On Fri, Jan 2, 2009 at 2:17 PM, Bryan Berry wrote:
> On Fri, 2009-01-02 at 12:46 -0500, Walter Bender wrote:
>> Bryan, I appreciate you raising this discussion thread. Unequivocally,
>> We need to make it easier for everyone to contribute.
>
> Thanks for your support!
>
>> In regard to your essay, I think it is important in this discussion to
>> make a clearer distinction between (1) the constraints on FLOSS
>> development in the developing world (i.e., the need to get paid); (2)
>> the tools one uses for that work (e.g., Flash vs Javascript/HTML vs
>> Python); (3) the role that "educational content" providers might play
>> in development (i.e., who are they and are they primarily writing
>> software?); and (4) the pedagogy we are espousing (e.g., is
>> constructionism the only game in town?).
>>
>> 1. While others have also observed that there is a need for profit in
>> the developing world for software developers, this by no means
>> disqualifies FLOSS development. It just means that the profit comes
>> not from selling a license to a closed package, but getting paid, for
>> example, by providing a service. There is not necessarily new money to
>> be had and it will take time to redirect money in the system that is
>> directed towards FLOSS developers. But that doesn't suggest that FLOSS
>> should be abandoned. It is clear that at least for education (and
>> voting), FLOSS is *the* right way.
>
> I am suggesting Flash because FLOSS should not exclusively be the domain
> of linux programmers.
>
There are many FLOSS programs that run on Windows, so I guess I am not
understanding your point. You mention some of them yourself: Gimp, for
example.
> Certainly, some programmers need to get paid but the point of my article
> is that there are many developers in the developing world more than
> happy to volunteer their time. Unfortunately, that time is constrained
> and we need to empower them to use tools they are familiar w/ rather
> than forcing them to become linux programmers.
>
> I agree that FLOSS is absolutely the right way. However that doesn't
> mean that XYZ developer uses Photoshop and Adobe Illustrator to create a
> flash activity, their resulting work can't be open-source too.
>
I don't think anyone is arguing that we should preclude people from
using whatever tools they have at hand.
>> 2. Low-cost/moderately powered hardware platforms do present some
>> constraints on what tools and solutions are suitable. Other
>> constraints include what skills are locally available and what rising
>> tides should be exploited. HTML/Javascript is probably the
>> lowest-hanging fruit, although Javascript performance on the OLPC-XO-1
>> hardware can be sluggish. But not as sluggish as Flash. It may be
>> worth someone making a concerted effort to help Rob fine-tune Gnash
>> (only Adobe can tune Flash) for the XO. The Sugar team will continue
>> to try to lower the barriers to developing native Sugar Activities and
>> putting Sugar wrappers around existing applications, be they written
>> in Javascript (e.g., SocialCalc) or Python or any other environment.
>> The foci are to provide ready access to the Journal and the
>> collaboration mechanisms ("convention over configuration"). (Wade's
>> note that arrived while I was composing this one is an example of what
>> we can do as a community to help individual development efforts.
>
> I find that Flash runs plenty fast using the proprietary flash player.
> It is only slightly slower than a pygtk app. Unfortunately, flash is
> quite sluggish using Gnash by a factor of 2 or 3 if it runs at all.
>
> I hope that my article's appearance in olpcnews.com will spur more
> developers to assist Rob on gnash.
>
> There is nothing in Adobe's Flash player licensing that restricts me
> from installing it Nepal's default XO image. Their licensing does
> restrict me from posting a software image that include the flash plugin
> on the Internet.
And there is nothing preventing you from using Adobe Flash if that is
what you want to do, at least for the time being.
>> 3. While I am thrilled that some classroom teachers are beginning to
>> participate directly in the software development process (e.g.,
>> TurtleArt and Labyrinth), I am convinced that their major contribution
>> will be more at the level of integration. There is a wonderful
>> "curriculum" developed in Peru on community publishing that leverages
>> Record, Write, Browse, and Chat. It didn't involve any Javascript or
>> Flash, just thoughtful synthesis of the available tools. There are
>> holes in our repertoire that preclude certain types of curriculum
>> development: I am working on some presentation/portfolio tools, for
>> example. What other holes need filling? And I am curious as to your
>> experience working with teachers within the Etoys framework. Was that
>> too difficult for them to master? How could we make it more
>> accessible? And what are the roadblocks to developing web content for
>> Sugar and/or OLPC-XOs?
>
> It takes a long time to train teachers to use Etoys who have never used
> a computer before. Etoys _requires_ mastery of the touchpad and that was
> more than we could teach in 2 weeks of training. Dragging and dropping
> is a non-trivial skill.
>
> I think we can train teachers familiar w/ computers how to use Etoys.
> Unfortunately, 95% of the teachers we deal and will deal w/ are not very
> familiar w/ computers.
>
> This is one of the major differences b/w Nepal's deployments and those
> of more developed countries like Uruguay.
I presume the same thing applies to Javascript and Flash that uses
drag and drop?
>> 4. Constructionism is not the only way. Our strategy at Sugar Labs is
>> to make a platform that encourages more constructionism in the
>> learning process, but that it would be a matter of lowering the
>> barriers to entry, not closing doors to other approaches. To repeat a
>> well-wore analogy: you can read a book in either PDF or Wiki format,
>> but the chances that the reader will make annotations, add to a
>> discussion, and even add to the content are all much greater with a
>> Wiki because it has the proper affordances for such interventions.
>> Providing such affordances to the learning experience might be
>> motivated by a specific pedagogy, but it does not preclude other
>> approaches.
>>
>> -walter
>
> I love constructionism but too often we focus exclusively high-level
> math and science and not "foundational" skills or art, literature,
> grammar, health, etc. By foundational skills I mean basic literacy and
> numeracy. Kids can't create an Etoys game until they can count properly.
> They can't read the dialogues until they understand phonics properly.
>
> Some vocabulary has to be memorized and kids have to be able to add #'s
> quickly in their head. When was the last time you reached for a
> calculator to compute 5 + 5? If you did, you would work much more
> slowly.
>
> I find that Sugar contributors from developed countries are focused more
> on high-level thinking because that is a deficiency in their local
> school systems. Their kids can do basic math and _usually_ know basic
> grammar. Poorer countries are focused on basic numeracy and literacy.
> You can't program until you can add and read.
>
> Countries like Peru and Brazil have schools where kids are ready to
> focus on high level problems. They also probably have schools struggling
> to impart basic literacy and numeracy.
I don't understand the construing of constructionism with "exclusively
high-level math and science" and I don't quite what you mean by
"foundational skills". I don't think anyone would argue that we don't
want numeracy and literacy to be "low shelf" tools in every child's
repertoire, but what does this have to do with the other topics in
this thread?
-walter
> --
> Bryan W. Berry
> Technology Director
> OLE Nepal, http://www.olenepal.org
>
>
--
Walter Bender
Sugar Labs
http://www.sugarlabs.org
From bryan at olenepal.org Fri Jan 2 14:46:03 2009
From: bryan at olenepal.org (Bryan Berry)
Date: Fri, 02 Jan 2009 11:46:03 -0800
Subject: [Sugar-devel] web-based activities (was Re: [IAEP] How to
Make Activity Designers Happy , Parts I and II)
In-Reply-To: <7087c32a0901021132s7423157av3ad1cfa4267b9326@mail.gmail.com>
References: <242851610901021018r4c84d249r8b348dc126c4bbe9@mail.gmail.com>
<7087c32a0901021132s7423157av3ad1cfa4267b9326@mail.gmail.com>
Message-ID: <1230925563.17108.81.camel@hitman>
this is neat Wade.
It is a little more heavy weight for some activities. both google gears,
flash, and the flash framework flex have some nice lightweight
persistence functionality.
On Fri, 2009-01-02 at 14:32 -0500, Wade Brainerd wrote:
> The work we did for WikiBrowse (the WikipediaES and WikipediaEN)
> activities would make a good starting point.
>
> First of all the Browse code should be integrated into Sugar. This
> has been discussed before, and makes sense since you guys are
> maintaining the Browse activity anyway.
>
> The Browse code would be provided as a base
> sugar.activity.webactivity.WebActivity class. Currently, "web-based"
> activities (not content bundles) need to manually find the path to the
> Browse installation (assuming there is one!) and import its modules
> which feels rather hacky.
>
> The sugar.activity.webactivity module should also provide a WebServer
> class. This class is a SimpleHTTPServer derivative which supports
> iterating and finding and returning an unused local port to serve
> over. The server would handle GET/POST requests to a special
> '/journal/' URL prefix, allowing DHTML scripts access to the
> activity's Journal entry.
>
> Finally, a web-activity launcher script should be created. This
> script launches the Sugar Browse code and supports a variety of
> command line options to control what parts of the Browse UI are
> enabled, and to set the home page. It should be possible to launch a
> Browse instance with nothing but the Activity toolbar for example.
>
> These steps will allow for three (or more!) different variations on
> "web-based" activities:
>
> 1) Static HTML and/or DHTML ala the existing .xol system. A
> collection of .html, css and .js files can be bundled as a .xo file.
> The included activity.info exec line calls web-activity with
> appropriate command line options.
>
> The advantage of this approach over .xol files is that the "web-based
> activity" appears as a first class object in the Sugar UI with an
> independent icon on the Home view. Further, since the
> sugar.activity.webactivity.WebServer is used, DHTML code can
> read/write from the activity's Journal entry.
>
> 2) Static HTML and/or DHTML with custom UI. In WikiBrowse, I
> subclassed WebActivity and added a new Search toolbar, which searches
> the wiki DB and retrieves a page of results. This is the same as
> variation 1, except instead of calling "web-activity", a new Python
> activity class is derived from sugar.activity.webactivity.WebActivity
> and modifies the UI in some way - adding toolbars, etc.
>
> 3) Static HTML and/or DHTML with custom server. In WikiBrowse, a
> custom webserver attaches to a local port and serves wiki pages. It
> decompresses and formats wiki pages before serving them up as XHTML.
> So in this variation, a simple Python WebServer class is derived from
> sugar.activity.webactivity.WebServer and the appropriate page request
> handing methods are added. The base WebServer class additionally
> handles GET/POST request to access the Journal entry for the activity.
>
> Doing this work would allow us to rewrite WikiBrowse in a much cleaner
> fashion, and would allow a whole range of first class Web-based Sugar
> activities.
>
> Cheers,
> Wade
>
> On Fri, Jan 2, 2009 at 1:18 PM, Tomeu Vizoso
> wrote:
> Hi,
>
> without needing to get into what is better for our
> deployments, I do
> see value in making easier to make Sugar activities using
> technologies
> such as HTML, CSS, etc
>
> Bryan, can we get into a more detailed view on what it would
> take
> ideally to create a new activity using such activities? Which
> would be
> the steps that an experienced web designer would need to take
> in order
> to create a Sugar activity?
>
> I'm sure that someone with basic knowledge of python could
> create some
> tools that make it much more easier than it is today. Also
> have some
> ideas about how those activities could interact with the
> journal and
> other Sugar features.
>
> Thanks,
>
> Tomeu
>
> On Fri, Jan 2, 2009 at 02:50, Bryan Berry
> wrote:
> > This is a draft of a multi-part article I plan to post to
> OLPC News.
> >
> > It is very long but I would very much appreciate your
> opinions and
> > feedback. Your input will make it a better article once
> published.
> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >
> > This OLPC project seems to be going pretty well as of late
> December
> > 2008. G1G1 v2 is well underway, there are a number of
> successful pilots
> > going on, and a number of larger-scale pilots will come
> online this
> > spring and coming summer.
> >
> > Still, there is a big gaping whole in the middle of our
> little education
> > project. There just aren't enough activities. Mind you, we
> have some
> > seriously awesome activities such as Etoys, Scratch, TamTam,
> and others.
> > We have tremendous depth but very limited breadth.
> >
> > By breadth, I mean interactive activities for language,
> history,
> > geology, health, etc. In order to expand the range of
> activities, we
> > need to recruit a lot more activity developers and make it
> dead-simple
> > for them to contribute.
> >
> > But Which Developers?
> >
> > Let's think about who we want to recruit. We're talking
> about breadth
> > here so we need experts on Nepali grammar, Pashto
> vocabulary, Philippine
> > history, and Andean geography. The good news is that there
> are
> > technically-oriented people out there that know these things
> and want to
> > help.
> >
> > We already have a hardcore team of dedicated hackers. We
> need them for
> > the work that hackers excel at: building infrastructure,
> testing the
> > limits of new systems. But now we need a different class of
> developer,
> > those that are focused on the presentation, game play and
> not system
> > internals.
> >
> > Based on these characteristics, let's call these people
> > designers. The good news is that there are lots of
> > designers-particularly in developing countries-that want to
> contribute
> > to OLPC. The bad news is that they don't know python. or GTK
> +. They may
> > not even be familiar with linux. They do know HTML, CSS,
> Javascript, and
> > Adobe Flash. Allow me to explain.
> >
> > Due to rise of the Internet and related boom in outsourcing,
> the vast,
> > vast majority of programmers in developing countries are web
> developers
> > (according to my own grossly unscientific survey). The rise
> of the
> > Internet has also led a lot of talented graphic designers in
> developing
> > and developed countries to learn web technologies. I even
> > wager that CSS/HTML/Javascript will become the de facto GUI
> technologies
> > in a few years time. > href="http://en.wikipedia.org/wiki/Pygtk">PyGTK won't
> take over the
> > world nor will VB.net.
> >
> > The popular term for this triumvirate of technologies is > href="http://en.wikipedia.org/wiki/AJAX">AJAX, with the
> difference
> > that AJAX applications typically require communication with
> a remote
> > server. I propose using web technologies for completely
> offline
> > activities. Adobe's Flash is basically a variant of AJAX
> that uses
> > dialects of Javascript ( >
> href="http://en.wikipedia.org/wiki/Actionscript">Actionscript) and
> > XML (MXML).
> >
> > Very few programmers in the developed world get paid to
> write desktop
> > linux apps. Still, open-source developers find learn and
> build pygtk,
> > mono, and KDE apps in their free-time. Developers in the
> developing
> > world are extremely enthusiastic about FOSS but not nearly
> as prolific
> > in creating open-source software due to a phenomenon I
> > call the "FOSS-Nepal Paradox."
> >
> > The >
> href="http://wiki.fossnepal.org/index.php?title=The_FOSS_Nepal_Community">FOSS Nepal community has won the award for best celebration of Software Freedom day for two years in a running. Despite all this enthusiasm the FOSS Nepal community is not very prolific in producing open-source code. The reason for this is that Nepal is not a wealthy country and that Open-Source is expensive to produce.
> >
> > Open-Source is Expensive
> >
> > Open-source software voraciously consumes a resource even
> more valuable
> > than hard cash, programmer time. Linus Torvalds could afford
> to spend
> > some of the most productive years of his life working
> without immediate
> > financial benefit. He could slack off in his classes without
> fear of
> > unemployment upon graduation. I doubt his parents were
> counting on him
> > to support them financially once he got a job.
> >
> > Most talented Nepali programmers I know do not have those
> luxuries. They
> > are under a lot of pressure to support their parents and
> extended
> > families, financially and otherwise. So Nepalis,
> Bangladeshis, Peruanos,
> > etc. certainly have the passion and ability to contribute to
> open-source
> > but their free time is significantly more limited.
> >
> > This doesn't mean that we should rely on developers from
> rich countries.
> > We simply need to radically lower the amount of time
> required to create
> > learning activities. I believe that many, many developers in
> the
> > developing world can contribute 3-5 hours per week. To make
> those few
> > hours productive we need to rework the default activity
> framework.
> >
> > >From what I can tell, the primary design goals of the
> default PyGTK
> > activity
> > framework are as follows:
> >
> > - Give the programmer maximum
> flexibility
- Fully exploit
> > the XO's hardware features
- Mesh nicely with
> Sugar
> >
> > These three goals are laudable and their hacker roots are
> obvious. The
> > problem is that these goals maximize the technology's
> potential rather
> > than programmer productivity. We need reach beyond the
> vi/emacs crowd
> > (Note: I wrote this article using emacs) to thos folks that
> the masters
> > of Photoshop, Adobe Illustrator, Eclipse, and GIMP.
> >
> > I propose a new set of design goals:
> >
> >
> > - Allow activity designers to quickly build
> activities utilizing
> > widely-used tools.
> > - Quickly reward effort with working behavior
> > - Mesh nicely with the Sugar UI
> >
> >
> > It's OK to be Opinionated
> >
> > We need an opinionated activity framework that makes
> infrastructure
> > choices for the designer so that she can focus presentation
> and
> > gameplay. Some may recognize this as the principle of >
> href="http://en.wikipedia.org/wiki/Convention_over_Configuration">Convention Over Configuration, a principle that two of the most popular web frameworks, Django and RubyOnRails, adhere to. Now a lot of geeks don't like Convention over Configuration--perl hackers especially--but they sure do allow you to create nice applications very quickly.
> >
> > Establishing an "opinionated" activity framework will in no
> way limit
> > the freedom of those hackers who want to go their own way.
> They can
> > always build their own activities from whatever tools they
> choose. The
> > whole point of a framework is to help people get started
> quickly but it
> > doesn't constrain anyone.
> >
> > This concludes part I. Here are some tantalizing morsels
> from Part II
> > of "How to Make Activity Designers Happy,"
> >
> >
> > - Where it's at: HTML, CSS, Javascript, and *gasp*
> Flash
> > - Nepal's Content Development Experience
> > - Aren't Kids going to create all learning
> activities so we don't
> > have to?
> >
> >
> >
> > Bryan Berry is the Technology Director of > href="http://www.olenepal.org">OLE Nepal and deadbeat
> co-editor of
> > OLPCNews.com. Christopher Marin contributed his knowledge
> about all
> > things web to this article
> >
> >
> >
> > In part 1, I talked about the paradoxical
> > nature of open-source communities in developing countries,
> flaws in
> > the current default activity development framework, and the
> urgent
> > need for a new framework that makes activity designers
> happy.
> >
> > By happy, I mean that the framework rewards their efforts
> almost
> > immediately (roughly 15 minutes of effort) and it lets them
> focus on
> > presentation and gameplay rather than infrastructure. Last
> time I
> > offered some vague ideas how this framework might function.
> This time
> > I will provide more details how this framework could work
> and why.
> >
> > Let's Ride The Internet Wave
> >
> > The Internet is the 300-pound gorilla in the
> software-engineering room
> > it will eat virtually everything, including your favorite
> desktop GUI
> > framework. All of the IDE's bend over backwards to support
> coding of
> > webapps, whether it is emacs, eclipse, or even vim. The
> software
> > industry is making huge investments into web technologies
> that support
> > the triumvirate of HTML/CSS/Javascript, witness Google's
> investment in
> > V8 javascript
> compiler and
> > Apple's investment in > href="http://en.wikipedia.org/wiki/WebKit">Webkit. I
> speculate
> > that there are many, many more developers working on GUI
> toolkits for
> > the web browser- such as JQuery, Prototype,
> Script.aculo.us-than for
> > GNOME or KDE desktop frameworks.
> >
> > The web will keep innovating at a breakneck pace. We need to
> ride that
> > wave of innovation.
> >
> > In the early days of OLPC, we all had a lot of grandiose and
> > impractical ideas. The educational systems of developing
> countries
> > would change overnight into constructionist hotbeds. Kids
> would build
> > their own activities, eliminating the need for large
> investments in
> > content development. A million PyGTK apps with built-in
> collaboration
> > and "View-Source" key would spontaneously bloom . . . Well,
> we're
> > older and wiser now. School systems anywhere are not blank
> slates that
> > we can redraw from scratch using cheap laptops and Etoys.
> Similarly,
> > we cannot expect thousands of developers to flock to a
> framework
> > (PyGTK) that is not commercially popular.
> >
> > Developing Country Developer Economics
> >
> > As I wrote in Part I, the economics of open-source in
> developing
> > countries is quite different than that in the developed
> > world. Developers there have ample enthusiasm for
> open-source but much
> > less time to contribute.
> >
> > We need to lower the barrier of entry significantly in order
> to use
> > their talents. In fact, we need to entice non-programmers
> such as
> > graphic designers. In my limited experience, graphic
> designers are
> > much better at designing learning activities than
> programmers. They
> > better appreciate aesthetics and visual story-telling.
> >
> > Web designers layout their work using CSS and (X)HTML. They
> implement
> > user interaction and animations using Javascript. They
> design their
> > work using Photoshop, GIMP, Adobe Illustrator, and sometimes
> > Eclipse. They know the features and dark areas of the
> Firefox web
> > browser. Sugar infrastructure developers, these people are
> your
> > customers. We need KARMA to enable them to quickly buidl
> activities
> > for the XO without having to learn a whole new skillset.
> From a
> > programmatic point of view, Browse needs to behave as much
> as possible
> > like Firefox. Any discrepancy will distract activity
> designers from
> > the more rewarding parts of activity development.
> >
> > Building Good KARMA
> >
> > Before we get too far, let's give this new activity
> framework a name
> > so I can save us all a lot of excess verbiage. I call it
> KARMA,
> > because the word is loosely-related to Nepal, my current
> residence,
> > and I like to think creating open-source learning activities
> gives an
> > individual good karma. Coincidentally, it is also the first
> two
> > syllables of Rabi Karmacharya's last name--an individual put
> a ton of
> > hard work and personal sacrifice into the OLPC project in
> Nepal.
> >
> > Well, I haven't actually made up my mind what the core
> technologies of
> > KARMA
> > should be. I need your help to work it out. Before I get
> into the
> > technologies, here are my priorities. 1) These tools
> maximize
> > programmer productivity and 2) are open-soure. Priority #1
> is much
> > more important than #2. 100% purely open-source activities
> that don't
> > exist don't help kids learn. The current pygtk framework is
> purely
> > open-source but you have to become a unix programmer to use
> it. As I
> > noted in Part I, the vast, vast majority of programmers in
> the
> > developing world are web developers and a successful
> activity
> > framework will allow them to re-use their existing skills
> and tools.
> >
> > I have settled on HTML and CSS for the presentation but it
> is tougher
> > to decide on the scripting toolset and on persistent data
> > storage. Flash handles animations really well and it is easy
> to
> > integrate audio into the animations. Adobe sells some really
> nice
> > WYSIWYG tools for editing animation and adding audio. A lot
> of
> > developers know flash so there is a large pool of talent we
> can draw
> > from. Did I forget to mention that Flash is proprietary?
> >
> > The closed-source issue not withstanding, Flash is the tool
> to
> > use. Some may be upset that Flash doesn't lend itself to
> "View Source"
> > functionality but learning programming is not the sum total
> of
> > education. Kids can do all the programming they ever want to
> w/ the
> > excellent Etoys and Scratch. Sorry to sound like a broken
> record, but
> > Afghani kids won't be able to view the source of Pashto
> grammar
> > activities that don't exist, let alone interactively learn
> the rules
> > of Pashto grammar.
> >
> > Flash Ain't Open-Source
> >
> > Flash is not _as_ closed-source as other software
> applications like
> > Windows. The Adobe has published the specification for their
> SWF file
> > format and the ActionScript 3.0 compiler is open-source.
> However, the
> > Adobe's development tools such as Adobe Animator,
> Illustrator,
> > Photoshop, etc. are not open-source. Nor is Adobe's flash
> player
> > plugin. There is the open-source Gnash player but it does
> not fully
> > support Actionscript 3 or Flash version 9. Rob Savoye and
> his team at
> > Open Media Now do a great job but they seriously lack
> resources. Note:
> > Rob
> > Savoye, please correct my egregious errors.
> >
> > Javascript Isn't Ready
> >
> > I put in a good number of research hours into this article.
> I really,
> > really wanted to find a pure javascript framework that could
> compete
> > with Flash. I couldn't find one that does. There are
> libraries like
> > DOJO, JQuery, and Processing.js
> > http://ejohn.org/blog/processingjs/. Unfortunately, there
> aren't any
> > IDE's that provide WYSIWYG animation editing for these
> tools. Every
> > try to edit photos from a text editor? It's painful, really
> > painful. So while real programmers use emacs (or vi, joe,
> sam, etc.),
> > designers use WYSIWYG GUI's.
> >
> > Sadly, Javascript can't use the Graphics Processing Unit
> like Flash
> > can. Ouch, it's a pain in the ass to couple animations with
> sound
> > files. Based on my research so far, pure javascript won't be
> able to
> > compete with Flash for at least the next several years.
> Please prove
> > me wrong. Please post a comment to this article linking to
> some
> > Javascript wonderfulness that pulls even with Flash.
> >
> >
> > I will continue with the assumption that KARMA will use
> flash. I will
> > happily revise this article ex post facto if someone in
> cyberspace
> > points me to a pure javascript solution that makes activity
> designers
> > happy.
> >
> > Building Momentum for Gnash
> >
> > I believe that the best way to increase interest in fully
> open-source
> > flash is to make Flash more central in the evolving
> open-source
> > education stack rather than minimizing its role. We
> definitely cannot
> > wait for Gnash to fully support every feature of the
> proprietary flash
> > before we begin using it. Open-Source starts when a single
> developer
> > "scratches an itch" as the proverb goes. It follows then
> that the best
> > way to bring Gnash up to speed we need to create a nasty,
> festering
> > sore that irritates the open-source community into action.
> >
> > Moving the Conversation Forward
> >
> > Many people will likely hate my promotion of Flash for
> learning
> > activities. It's OK if you hate me and Flash. I do hope you
> recognize
> > that we need a more developer-centric activity framework
> that uses web
> > technologies.
> >
> > I have a lot more to write about Nepal's experiences
> developing
> > learning activities and my ideas on Convention over
> Configuration in
> > sugar activities. I will save those for another day.
> >
> >
> > --
> > Bryan W. Berry
> > Technology Director
> > OLE Nepal, http://www.olenepal.org
> >
> > _______________________________________________
> > IAEP -- It's An Education Project (not a laptop project!)
> > IAEP at lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/iaep
> >
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
--
Bryan W. Berry
Technology Director
OLE Nepal, http://www.olenepal.org
From walter.bender at gmail.com Fri Jan 2 14:48:33 2009
From: walter.bender at gmail.com (Walter Bender)
Date: Fri, 2 Jan 2009 14:48:33 -0500
Subject: [Sugar-devel] TA with sensors
In-Reply-To:
References:
Message-ID:
Thanks for this background.
I think that the try/exception mechanism is adequate for our needs. It
will be otherwise trivial for me to add the sensor features to the
main branch of TA... I'll add it to the next release.
I wonder if there is a mechanism we can call upon (Sugar should
perhaps provide this) that will tell us that we are being sent to the
background so that we can only reinitialize when we go away and come
back? It seems that for every call to the sensor, it is a large
overhead to incur...
-walter
On Fri, Jan 2, 2009 at 2:25 PM, Arjun Sarwal wrote:
> Hello Walter,
>
> Thank you for the new year wishes. Best wishes to you too for the new
> year! (hope you received my card too)
>
> A few points regarding adding sensor support
>
> * Calls to Alsamixer to set the DC mode on/off will result in an
> exception on one's normal laptop. This is because the DC mode controls
> don't exist in the Alsamixer of a normal laptop (even sugar emulation
> makes calls to the laptop's default alsamixer)
>
> * I had put in initializations before each call to the sensor because
> - user may switch to another Activity in between a session of Turtle
> Art -- the other Activity may use the laptop's sound device. The
> other Activity may alter the sound device settings.
> - unless a call for sensor input is being made, I didn't want to keep
> the capture device active.
> The capture device can be thought to be in a state of 'recording
> sound' when one is getting sensor input data, hence only one
> Activity/program can have access to it at one time.
> However, any suggestions you may have on the above implementation
> would be very welcome.
>
>
> * If it helps, I am summarizing approximately the changes I made in
> TurtleArt to add sensor support and some relevant lines to look at
> within the TA with Sensors code that I had made for the earlier (non
> SVG version of TAwithSensors):
> Referring to the version of the online git tree ('Initial import')
> (http://dev.laptop.org/git?p=users/arjs/TurtleArtwithSensors;a=tree;h=3f22f9f86d60f6160268c52009273eba82dba465;hb=3f22f9f86d60f6160268c52009273eba82dba465)
>
> - audiograb.py as an additional file was included completely
> - talogo.py :
> (note that lines 8 and 9 in this version of git tree would need to be
> changed to
> from numpy.oldnumeric import *
> from numpy.fft import * )
> lines 8,9,11,12 were added
> lines 366 onwards till the end have been added
> -tasetup.py: lines 47 to 51 to account for the additional sensor
> blocks in the UI
>
> As you can see from the code of talogo.py , the approach involves a
> lot of painful starting the whole gstreamer pipeline, getting one
> sample then stopping the pipeline. An overkill for getting just one
> sample, but there is no way unless python alsa audio is included in
> the build system. The approach with python alsa audio is work in
> progress here (
> http://dev.laptop.org/git?p=users/arjs/TurtleArtwithSensors;a=tree )
>
> I want to work on incorporating sensor support into the SVG version of
> TA that you have made, but my current day job isn't leaving me any
> time these days to do anything else. I will get to it as soon as I get
> the opportunity, but if in the meanwhile you get a chance to do it -
> it'd be great.
>
> Please let me know if I can help further.
>
> Kind Regards
> Arjun
>
> On Fri, Jan 2, 2009 at 3:18 AM, Walter Bender wrote:
>>
>> I've begun folding TA with sensors into TA. I use an exception to
>> catch the calls to set DC Mode in Alsamixer, so it seems to run fine
>> on my normal laptop using the mic input. But when I look at the logs,
>> it seems that there is a lot of initialization that happens with every
>> call to the sensor. Is that all necessary? Can we just check for
>> changes after the first time?
>>
>> -walter
>>
>>
>>
>> # test to see if DC Mode is enabled
>> try:
>> self.dcmode = Mixer('DC Mode Enable')
>> self.bias = Mixer('V_REFOUT Enable')
>> self.has_dcmode = True
>> except:
>> print "DC Mode unavailable"
>> self.has_dcmode = False
>>
>>
>>
>> Walter Bender
>> Sugar Labs
>> http://www.sugarlabs.org
>
>
>
> --
> Arjun Sarwal
>
--
Walter Bender
Sugar Labs
http://www.sugarlabs.org
From bryan at olenepal.org Fri Jan 2 14:53:28 2009
From: bryan at olenepal.org (Bryan Berry)
Date: Fri, 02 Jan 2009 11:53:28 -0800
Subject: [Sugar-devel] How to Make Activity Designers Happy ,
Parts I and II
In-Reply-To:
References: <1230861040.17108.4.camel__8009.18864920295$1230861178$gmane$org@hitman>
<1230874359.17108.16.camel@hitman>
<1230912293.17108.41.camel@hitman>
<1230923827.17108.65.camel@hitman>
Message-ID: <1230926008.17108.89.camel@hitman>
On Fri, 2009-01-02 at 14:41 -0500, Walter Bender wrote:
> >> 2. Low-cost/moderately powered hardware platforms do present some
> >> constraints on what tools and solutions are suitable. Other
> >> constraints include what skills are locally available and what rising
> >> tides should be exploited. HTML/Javascript is probably the
> >> lowest-hanging fruit, although Javascript performance on the OLPC-XO-1
> >> hardware can be sluggish. But not as sluggish as Flash. It may be
> >> worth someone making a concerted effort to help Rob fine-tune Gnash
> >> (only Adobe can tune Flash) for the XO. The Sugar team will continue
> >> to try to lower the barriers to developing native Sugar Activities and
> >> putting Sugar wrappers around existing applications, be they written
> >> in Javascript (e.g., SocialCalc) or Python or any other environment.
> >> The foci are to provide ready access to the Journal and the
> >> collaboration mechanisms ("convention over configuration"). (Wade's
> >> note that arrived while I was composing this one is an example of what
> >> we can do as a community to help individual development efforts.
> >
> > I find that Flash runs plenty fast using the proprietary flash player.
> > It is only slightly slower than a pygtk app. Unfortunately, flash is
> > quite sluggish using Gnash by a factor of 2 or 3 if it runs at all.
> >
> > I hope that my article's appearance in olpcnews.com will spur more
> > developers to assist Rob on gnash.
> >
> > There is nothing in Adobe's Flash player licensing that restricts me
> > from installing it Nepal's default XO image. Their licensing does
> > restrict me from posting a software image that include the flash plugin
> > on the Internet.
>
> And there is nothing preventing you from using Adobe Flash if that is
> what you want to do, at least for the time being.
>
> >> 3. While I am thrilled that some classroom teachers are beginning to
> >> participate directly in the software development process (e.g.,
> >> TurtleArt and Labyrinth), I am convinced that their major contribution
> >> will be more at the level of integration. There is a wonderful
> >> "curriculum" developed in Peru on community publishing that leverages
> >> Record, Write, Browse, and Chat. It didn't involve any Javascript or
> >> Flash, just thoughtful synthesis of the available tools. There are
> >> holes in our repertoire that preclude certain types of curriculum
> >> development: I am working on some presentation/portfolio tools, for
> >> example. What other holes need filling? And I am curious as to your
> >> experience working with teachers within the Etoys framework. Was that
> >> too difficult for them to master? How could we make it more
> >> accessible? And what are the roadblocks to developing web content for
> >> Sugar and/or OLPC-XOs?
> >
> > It takes a long time to train teachers to use Etoys who have never used
> > a computer before. Etoys _requires_ mastery of the touchpad and that was
> > more than we could teach in 2 weeks of training. Dragging and dropping
> > is a non-trivial skill.
> >
> > I think we can train teachers familiar w/ computers how to use Etoys.
> > Unfortunately, 95% of the teachers we deal and will deal w/ are not very
> > familiar w/ computers.
> >
> > This is one of the major differences b/w Nepal's deployments and those
> > of more developed countries like Uruguay.
>
> I presume the same thing applies to Javascript and Flash that uses
> drag and drop?
It is does if you require a lot of dragging-and-dropping together w/
right-clicking. For example, our teachers got the hang of Draw during
training but they struggled w/ Etoys. They could do
point-click-activities like GCompris, E-Paath, Maze, etc. w/out a
problem
> >> 4. Constructionism is not the only way. Our strategy at Sugar Labs is
> >> to make a platform that encourages more constructionism in the
> >> learning process, but that it would be a matter of lowering the
> >> barriers to entry, not closing doors to other approaches. To repeat a
> >> well-wore analogy: you can read a book in either PDF or Wiki format,
> >> but the chances that the reader will make annotations, add to a
> >> discussion, and even add to the content are all much greater with a
> >> Wiki because it has the proper affordances for such interventions.
> >> Providing such affordances to the learning experience might be
> >> motivated by a specific pedagogy, but it does not preclude other
> >> approaches.
> >>
> >> -walter
> >
> > I love constructionism but too often we focus exclusively high-level
> > math and science and not "foundational" skills or art, literature,
> > grammar, health, etc. By foundational skills I mean basic literacy and
> > numeracy. Kids can't create an Etoys game until they can count properly.
> > They can't read the dialogues until they understand phonics properly.
> >
> > Some vocabulary has to be memorized and kids have to be able to add #'s
> > quickly in their head. When was the last time you reached for a
> > calculator to compute 5 + 5? If you did, you would work much more
> > slowly.
> >
> > I find that Sugar contributors from developed countries are focused more
> > on high-level thinking because that is a deficiency in their local
> > school systems. Their kids can do basic math and _usually_ know basic
> > grammar. Poorer countries are focused on basic numeracy and literacy.
> > You can't program until you can add and read.
> >
> > Countries like Peru and Brazil have schools where kids are ready to
> > focus on high level problems. They also probably have schools struggling
> > to impart basic literacy and numeracy.
>
> I don't understand the construing of constructionism with "exclusively
> high-level math and science" and I don't quite what you mean by
> "foundational skills". I don't think anyone would argue that we don't
> want numeracy and literacy to be "low shelf" tools in every child's
> repertoire, but what does this have to do with the other topics in
> this thread?
>
It has to do w/ this thread because it is easy to create simple
animations using Flash but hard to add collaboration and "View Source."
I am trying to make the point that a lot of activities don't need those
features in order to be very effective.
> > --
> > Bryan W. Berry
> > Technology Director
> > OLE Nepal, http://www.olenepal.org
> >
> >
>
>
>
--
Bryan W. Berry
Technology Director
OLE Nepal, http://www.olenepal.org
From wadetb at gmail.com Fri Jan 2 14:54:53 2009
From: wadetb at gmail.com (Wade Brainerd)
Date: Fri, 2 Jan 2009 14:54:53 -0500
Subject: [Sugar-devel] [IAEP] How to Make Activity Designers Happy ,
Parts I and II
In-Reply-To:
References: <1230861040.17108.4.camel__8009.18864920295$1230861178$gmane$org@hitman>
<1230874359.17108.16.camel@hitman>
<1230912293.17108.41.camel@hitman>
<1230923827.17108.65.camel@hitman>
Message-ID: <7087c32a0901021154r506f1f76k8b61cb0a68b2c672@mail.gmail.com>
On Fri, Jan 2, 2009 at 2:41 PM, Walter Bender wrote:
> I don't think anyone is arguing that we should preclude people from
> using whatever tools they have at hand.
>
I think the question is how well the Sugar community *supports* using using
a particular tool (Flash, Javascript) by making it convenient, not whether
they are precluded. This is more an allocation of resources question than a
philosophical one.
> I find that Sugar contributors from developed countries are focused more
> > on high-level thinking because that is a deficiency in their local
> > school systems. Their kids can do basic math and _usually_ know basic
> > grammar. Poorer countries are focused on basic numeracy and literacy.
> > You can't program until you can add and read.
> >
> > Countries like Peru and Brazil have schools where kids are ready to
> > focus on high level problems. They also probably have schools struggling
> > to impart basic literacy and numeracy.
>
> I don't understand the construing of constructionism with "exclusively
> high-level math and science" and I don't quite what you mean by
> "foundational skills". I don't think anyone would argue that we don't
> want numeracy and literacy to be "low shelf" tools in every child's
> repertoire, but what does this have to do with the other topics in
> this thread?
I read this as saying that the constructivist activities that have been
developed *so far* by programmers in developed countries tend to focus on
high level concept learning rather than foundational skills. And I agree
with this statement.
I'm currently working on Typing Turtle, a typing trainer for the XO. One
could say "they have Write and Chat, they will learn how to type" - that
would be a constructivist approach. I feel like there is a need for more
focused training of fundamental 'low shelf' skills, that's why I'm working
on that particular activity.
-Wade
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090102/a4c1b21e/attachment.htm
From wadetb at gmail.com Fri Jan 2 15:00:08 2009
From: wadetb at gmail.com (Wade Brainerd)
Date: Fri, 2 Jan 2009 15:00:08 -0500
Subject: [Sugar-devel] web-based activities (was Re: [IAEP] How to Make
Activity Designers Happy , Parts I and II)
In-Reply-To: <1230925563.17108.81.camel@hitman>
References: <242851610901021018r4c84d249r8b348dc126c4bbe9@mail.gmail.com>
<7087c32a0901021132s7423157av3ad1cfa4267b9326@mail.gmail.com>
<1230925563.17108.81.camel@hitman>
Message-ID: <7087c32a0901021200g40a5c9f9s86a5f1a5d1224d4e@mail.gmail.com>
I'm not sure about Gears, but I have worked with the Flash persistence stuff
before - you're right, it's quite convenient. It would be great to build
support for finding the storage file and copying it to/from the Journal.
It could even be done automatically by the WebActivity class (or else a
separate FlashActivity class if we want to avoid loading Firefox) class,
making it transparent to the Flash programmer.
-Wade
On Fri, Jan 2, 2009 at 2:46 PM, Bryan Berry wrote:
> this is neat Wade.
>
> It is a little more heavy weight for some activities. both google gears,
> flash, and the flash framework flex have some nice lightweight
> persistence functionality.
>
> On Fri, 2009-01-02 at 14:32 -0500, Wade Brainerd wrote:
> > The work we did for WikiBrowse (the WikipediaES and WikipediaEN)
> > activities would make a good starting point.
> >
> > First of all the Browse code should be integrated into Sugar. This
> > has been discussed before, and makes sense since you guys are
> > maintaining the Browse activity anyway.
> >
> > The Browse code would be provided as a base
> > sugar.activity.webactivity.WebActivity class. Currently, "web-based"
> > activities (not content bundles) need to manually find the path to the
> > Browse installation (assuming there is one!) and import its modules
> > which feels rather hacky.
> >
> > The sugar.activity.webactivity module should also provide a WebServer
> > class. This class is a SimpleHTTPServer derivative which supports
> > iterating and finding and returning an unused local port to serve
> > over. The server would handle GET/POST requests to a special
> > '/journal/' URL prefix, allowing DHTML scripts access to the
> > activity's Journal entry.
> >
> > Finally, a web-activity launcher script should be created. This
> > script launches the Sugar Browse code and supports a variety of
> > command line options to control what parts of the Browse UI are
> > enabled, and to set the home page. It should be possible to launch a
> > Browse instance with nothing but the Activity toolbar for example.
> >
> > These steps will allow for three (or more!) different variations on
> > "web-based" activities:
> >
> > 1) Static HTML and/or DHTML ala the existing .xol system. A
> > collection of .html, css and .js files can be bundled as a .xo file.
> > The included activity.info exec line calls web-activity with
> > appropriate command line options.
> >
> > The advantage of this approach over .xol files is that the "web-based
> > activity" appears as a first class object in the Sugar UI with an
> > independent icon on the Home view. Further, since the
> > sugar.activity.webactivity.WebServer is used, DHTML code can
> > read/write from the activity's Journal entry.
> >
> > 2) Static HTML and/or DHTML with custom UI. In WikiBrowse, I
> > subclassed WebActivity and added a new Search toolbar, which searches
> > the wiki DB and retrieves a page of results. This is the same as
> > variation 1, except instead of calling "web-activity", a new Python
> > activity class is derived from sugar.activity.webactivity.WebActivity
> > and modifies the UI in some way - adding toolbars, etc.
> >
> > 3) Static HTML and/or DHTML with custom server. In WikiBrowse, a
> > custom webserver attaches to a local port and serves wiki pages. It
> > decompresses and formats wiki pages before serving them up as XHTML.
> > So in this variation, a simple Python WebServer class is derived from
> > sugar.activity.webactivity.WebServer and the appropriate page request
> > handing methods are added. The base WebServer class additionally
> > handles GET/POST request to access the Journal entry for the activity.
> >
> > Doing this work would allow us to rewrite WikiBrowse in a much cleaner
> > fashion, and would allow a whole range of first class Web-based Sugar
> > activities.
> >
> > Cheers,
> > Wade
> >
> > On Fri, Jan 2, 2009 at 1:18 PM, Tomeu Vizoso
> > wrote:
> > Hi,
> >
> > without needing to get into what is better for our
> > deployments, I do
> > see value in making easier to make Sugar activities using
> > technologies
> > such as HTML, CSS, etc
> >
> > Bryan, can we get into a more detailed view on what it would
> > take
> > ideally to create a new activity using such activities? Which
> > would be
> > the steps that an experienced web designer would need to take
> > in order
> > to create a Sugar activity?
> >
> > I'm sure that someone with basic knowledge of python could
> > create some
> > tools that make it much more easier than it is today. Also
> > have some
> > ideas about how those activities could interact with the
> > journal and
> > other Sugar features.
> >
> > Thanks,
> >
> > Tomeu
> >
> > On Fri, Jan 2, 2009 at 02:50, Bryan Berry
> > wrote:
> > > This is a draft of a multi-part article I plan to post to
> > OLPC News.
> > >
> > > It is very long but I would very much appreciate your
> > opinions and
> > > feedback. Your input will make it a better article once
> > published.
> > >
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >
> > > This OLPC project seems to be going pretty well as of late
> > December
> > > 2008. G1G1 v2 is well underway, there are a number of
> > successful pilots
> > > going on, and a number of larger-scale pilots will come
> > online this
> > > spring and coming summer.
> > >
> > > Still, there is a big gaping whole in the middle of our
> > little education
> > > project. There just aren't enough activities. Mind you, we
> > have some
> > > seriously awesome activities such as Etoys, Scratch, TamTam,
> > and others.
> > > We have tremendous depth but very limited breadth.
> > >
> > > By breadth, I mean interactive activities for language,
> > history,
> > > geology, health, etc. In order to expand the range of
> > activities, we
> > > need to recruit a lot more activity developers and make it
> > dead-simple
> > > for them to contribute.
> > >
> > > But Which Developers?
> > >
> > > Let's think about who we want to recruit. We're talking
> > about breadth
> > > here so we need experts on Nepali grammar, Pashto
> > vocabulary, Philippine
> > > history, and Andean geography. The good news is that there
> > are
> > > technically-oriented people out there that know these things
> > and want to
> > > help.
> > >
> > > We already have a hardcore team of dedicated hackers. We
> > need them for
> > > the work that hackers excel at: building infrastructure,
> > testing the
> > > limits of new systems. But now we need a different class of
> > developer,
> > > those that are focused on the presentation, game play and
> > not system
> > > internals.
> > >
> > > Based on these characteristics, let's call these people
> > > designers. The good news is that there are lots of
> > > designers-particularly in developing countries-that want to
> > contribute
> > > to OLPC. The bad news is that they don't know python. or GTK
> > +. They may
> > > not even be familiar with linux. They do know HTML, CSS,
> > Javascript, and
> > > Adobe Flash. Allow me to explain.
> > >
> > > Due to rise of the Internet and related boom in outsourcing,
> > the vast,
> > > vast majority of programmers in developing countries are web
> > developers
> > > (according to my own grossly unscientific survey). The rise
> > of the
> > > Internet has also led a lot of talented graphic designers in
> > developing
> > > and developed countries to learn web technologies. I even
> > > wager that CSS/HTML/Javascript will become the de facto GUI
> > technologies
> > > in a few years time. > > href="http://en.wikipedia.org/wiki/Pygtk">PyGTK won't
> > take over the
> > > world nor will VB.net.
> > >
> > > The popular term for this triumvirate of technologies is > > href="http://en.wikipedia.org/wiki/AJAX">AJAX, with the
> > difference
> > > that AJAX applications typically require communication with
> > a remote
> > > server. I propose using web technologies for completely
> > offline
> > > activities. Adobe's Flash is basically a variant of AJAX
> > that uses
> > > dialects of Javascript ( > >
> > href="http://en.wikipedia.org/wiki/Actionscript">Actionscript)
> and
> > > XML (MXML).
> > >
> > > Very few programmers in the developed world get paid to
> > write desktop
> > > linux apps. Still, open-source developers find learn and
> > build pygtk,
> > > mono, and KDE apps in their free-time. Developers in the
> > developing
> > > world are extremely enthusiastic about FOSS but not nearly
> > as prolific
> > > in creating open-source software due to a phenomenon I
> > > call the "FOSS-Nepal Paradox."
> > >
> > > The > >
> > href="
> http://wiki.fossnepal.org/index.php?title=The_FOSS_Nepal_Community">FOSS
> Nepal community has won the award for best
> celebration of Software Freedom day for two years in a running. Despite all
> this enthusiasm the FOSS Nepal community is not very prolific in producing
> open-source code. The reason for this is that Nepal is not a wealthy country
> and that Open-Source is expensive to produce.
> > >
> > > Open-Source is Expensive
> > >
> > > Open-source software voraciously consumes a resource even
> > more valuable
> > > than hard cash, programmer time. Linus Torvalds could afford
> > to spend
> > > some of the most productive years of his life working
> > without immediate
> > > financial benefit. He could slack off in his classes without
> > fear of
> > > unemployment upon graduation. I doubt his parents were
> > counting on him
> > > to support them financially once he got a job.
> > >
> > > Most talented Nepali programmers I know do not have those
> > luxuries. They
> > > are under a lot of pressure to support their parents and
> > extended
> > > families, financially and otherwise. So Nepalis,
> > Bangladeshis, Peruanos,
> > > etc. certainly have the passion and ability to contribute to
> > open-source
> > > but their free time is significantly more limited.
> > >
> > > This doesn't mean that we should rely on developers from
> > rich countries.
> > > We simply need to radically lower the amount of time
> > required to create
> > > learning activities. I believe that many, many developers in
> > the
> > > developing world can contribute 3-5 hours per week. To make
> > those few
> > > hours productive we need to rework the default activity
> > framework.
> > >
> > > >From what I can tell, the primary design goals of the
> > default PyGTK
> > > activity
> > > framework are as follows:
> > >
> > > - Give the programmer maximum
> > flexibility
- Fully exploit
> > > the XO's hardware features
- Mesh nicely with
> > Sugar
> > >
> > > These three goals are laudable and their hacker roots are
> > obvious. The
> > > problem is that these goals maximize the technology's
> > potential rather
> > > than programmer productivity. We need reach beyond the
> > vi/emacs crowd
> > > (Note: I wrote this article using emacs) to thos folks that
> > the masters
> > > of Photoshop, Adobe Illustrator, Eclipse, and GIMP.
> > >
> > > I propose a new set of design goals:
> > >
> > >
> > > - Allow activity designers to quickly build
> > activities utilizing
> > > widely-used tools.
> > > - Quickly reward effort with working behavior
> > > - Mesh nicely with the Sugar UI
> > >
> > >
> > > It's OK to be Opinionated
> > >
> > > We need an opinionated activity framework that makes
> > infrastructure
> > > choices for the designer so that she can focus presentation
> > and
> > > gameplay. Some may recognize this as the principle of > >
> > href="http://en.wikipedia.org/wiki/Convention_over_Configuration">Convention
> Over Configuration, a principle that two of the most popular web
> frameworks, Django and RubyOnRails, adhere to. Now a lot of geeks don't like
> Convention over Configuration--perl hackers especially--but they sure do
> allow you to create nice applications very quickly.
> > >
> > > Establishing an "opinionated" activity framework will in no
> > way limit
> > > the freedom of those hackers who want to go their own way.
> > They can
> > > always build their own activities from whatever tools they
> > choose. The
> > > whole point of a framework is to help people get started
> > quickly but it
> > > doesn't constrain anyone.
> > >
> > > This concludes part I. Here are some tantalizing morsels
> > from Part II
> > > of "How to Make Activity Designers Happy,"
> > >
> > >
> > > - Where it's at: HTML, CSS, Javascript, and *gasp*
> > Flash
> > > - Nepal's Content Development Experience
> > > - Aren't Kids going to create all learning
> > activities so we don't
> > > have to?
> > >
> > >
> > >
> > > Bryan Berry is the Technology Director of > > href="http://www.olenepal.org">OLE Nepal and deadbeat
> > co-editor of
> > > OLPCNews.com. Christopher Marin contributed his knowledge
> > about all
> > > things web to this article
> > >
> > >
> > >
> > > In part 1, I talked about the paradoxical
> > > nature of open-source communities in developing countries,
> > flaws in
> > > the current default activity development framework, and the
> > urgent
> > > need for a new framework that makes activity designers
> > happy.
> > >
> > > By happy, I mean that the framework rewards their efforts
> > almost
> > > immediately (roughly 15 minutes of effort) and it lets them
> > focus on
> > > presentation and gameplay rather than infrastructure. Last
> > time I
> > > offered some vague ideas how this framework might function.
> > This time
> > > I will provide more details how this framework could work
> > and why.
> > >
> > > Let's Ride The Internet Wave
> > >
> > > The Internet is the 300-pound gorilla in the
> > software-engineering room
> > > it will eat virtually everything, including your favorite
> > desktop GUI
> > > framework. All of the IDE's bend over backwards to support
> > coding of
> > > webapps, whether it is emacs, eclipse, or even vim. The
> > software
> > > industry is making huge investments into web technologies
> > that support
> > > the triumvirate of HTML/CSS/Javascript, witness Google's
> > investment in
> > > V8 javascript
> > compiler and
> > > Apple's investment in > > href="http://en.wikipedia.org/wiki/WebKit">Webkit. I
> > speculate
> > > that there are many, many more developers working on GUI
> > toolkits for
> > > the web browser- such as JQuery, Prototype,
> > Script.aculo.us-than for
> > > GNOME or KDE desktop frameworks.
> > >
> > > The web will keep innovating at a breakneck pace. We need to
> > ride that
> > > wave of innovation.
> > >
> > > In the early days of OLPC, we all had a lot of grandiose and
> > > impractical ideas. The educational systems of developing
> > countries
> > > would change overnight into constructionist hotbeds. Kids
> > would build
> > > their own activities, eliminating the need for large
> > investments in
> > > content development. A million PyGTK apps with built-in
> > collaboration
> > > and "View-Source" key would spontaneously bloom . . . Well,
> > we're
> > > older and wiser now. School systems anywhere are not blank
> > slates that
> > > we can redraw from scratch using cheap laptops and Etoys.
> > Similarly,
> > > we cannot expect thousands of developers to flock to a
> > framework
> > > (PyGTK) that is not commercially popular.
> > >
> > > Developing Country Developer Economics
> > >
> > > As I wrote in Part I, the economics of open-source in
> > developing
> > > countries is quite different than that in the developed
> > > world. Developers there have ample enthusiasm for
> > open-source but much
> > > less time to contribute.
> > >
> > > We need to lower the barrier of entry significantly in order
> > to use
> > > their talents. In fact, we need to entice non-programmers
> > such as
> > > graphic designers. In my limited experience, graphic
> > designers are
> > > much better at designing learning activities than
> > programmers. They
> > > better appreciate aesthetics and visual story-telling.
> > >
> > > Web designers layout their work using CSS and (X)HTML. They
> > implement
> > > user interaction and animations using Javascript. They
> > design their
> > > work using Photoshop, GIMP, Adobe Illustrator, and sometimes
> > > Eclipse. They know the features and dark areas of the
> > Firefox web
> > > browser. Sugar infrastructure developers, these people are
> > your
> > > customers. We need KARMA to enable them to quickly buidl
> > activities
> > > for the XO without having to learn a whole new skillset.
> > From a
> > > programmatic point of view, Browse needs to behave as much
> > as possible
> > > like Firefox. Any discrepancy will distract activity
> > designers from
> > > the more rewarding parts of activity development.
> > >
> > > Building Good KARMA
> > >
> > > Before we get too far, let's give this new activity
> > framework a name
> > > so I can save us all a lot of excess verbiage. I call it
> > KARMA,
> > > because the word is loosely-related to Nepal, my current
> > residence,
> > > and I like to think creating open-source learning activities
> > gives an
> > > individual good karma. Coincidentally, it is also the first
> > two
> > > syllables of Rabi Karmacharya's last name--an individual put
> > a ton of
> > > hard work and personal sacrifice into the OLPC project in
> > Nepal.
> > >
> > > Well, I haven't actually made up my mind what the core
> > technologies of
> > > KARMA
> > > should be. I need your help to work it out. Before I get
> > into the
> > > technologies, here are my priorities. 1) These tools
> > maximize
> > > programmer productivity and 2) are open-soure. Priority #1
> > is much
> > > more important than #2. 100% purely open-source activities
> > that don't
> > > exist don't help kids learn. The current pygtk framework is
> > purely
> > > open-source but you have to become a unix programmer to use
> > it. As I
> > > noted in Part I, the vast, vast majority of programmers in
> > the
> > > developing world are web developers and a successful
> > activity
> > > framework will allow them to re-use their existing skills
> > and tools.
> > >
> > > I have settled on HTML and CSS for the presentation but it
> > is tougher
> > > to decide on the scripting toolset and on persistent data
> > > storage. Flash handles animations really well and it is easy
> > to
> > > integrate audio into the animations. Adobe sells some really
> > nice
> > > WYSIWYG tools for editing animation and adding audio. A lot
> > of
> > > developers know flash so there is a large pool of talent we
> > can draw
> > > from. Did I forget to mention that Flash is proprietary?
> > >
> > > The closed-source issue not withstanding, Flash is the tool
> > to
> > > use. Some may be upset that Flash doesn't lend itself to
> > "View Source"
> > > functionality but learning programming is not the sum total
> > of
> > > education. Kids can do all the programming they ever want to
> > w/ the
> > > excellent Etoys and Scratch. Sorry to sound like a broken
> > record, but
> > > Afghani kids won't be able to view the source of Pashto
> > grammar
> > > activities that don't exist, let alone interactively learn
> > the rules
> > > of Pashto grammar.
> > >
> > > Flash Ain't Open-Source
> > >
> > > Flash is not _as_ closed-source as other software
> > applications like
> > > Windows. The Adobe has published the specification for their
> > SWF file
> > > format and the ActionScript 3.0 compiler is open-source.
> > However, the
> > > Adobe's development tools such as Adobe Animator,
> > Illustrator,
> > > Photoshop, etc. are not open-source. Nor is Adobe's flash
> > player
> > > plugin. There is the open-source Gnash player but it does
> > not fully
> > > support Actionscript 3 or Flash version 9. Rob Savoye and
> > his team at
> > > Open Media Now do a great job but they seriously lack
> > resources. Note:
> > > Rob
> > > Savoye, please correct my egregious errors.
> > >
> > > Javascript Isn't Ready
> > >
> > > I put in a good number of research hours into this article.
> > I really,
> > > really wanted to find a pure javascript framework that could
> > compete
> > > with Flash. I couldn't find one that does. There are
> > libraries like
> > > DOJO, JQuery, and Processing.js
> > > http://ejohn.org/blog/processingjs/. Unfortunately, there
> > aren't any
> > > IDE's that provide WYSIWYG animation editing for these
> > tools. Every
> > > try to edit photos from a text editor? It's painful, really
> > > painful. So while real programmers use emacs (or vi, joe,
> > sam, etc.),
> > > designers use WYSIWYG GUI's.
> > >
> > > Sadly, Javascript can't use the Graphics Processing Unit
> > like Flash
> > > can. Ouch, it's a pain in the ass to couple animations with
> > sound
> > > files. Based on my research so far, pure javascript won't be
> > able to
> > > compete with Flash for at least the next several years.
> > Please prove
> > > me wrong. Please post a comment to this article linking to
> > some
> > > Javascript wonderfulness that pulls even with Flash.
> > >
> > >
> > > I will continue with the assumption that KARMA will use
> > flash. I will
> > > happily revise this article ex post facto if someone in
> > cyberspace
> > > points me to a pure javascript solution that makes activity
> > designers
> > > happy.
> > >
> > > Building Momentum for Gnash
> > >
> > > I believe that the best way to increase interest in fully
> > open-source
> > > flash is to make Flash more central in the evolving
> > open-source
> > > education stack rather than minimizing its role. We
> > definitely cannot
> > > wait for Gnash to fully support every feature of the
> > proprietary flash
> > > before we begin using it. Open-Source starts when a single
> > developer
> > > "scratches an itch" as the proverb goes. It follows then
> > that the best
> > > way to bring Gnash up to speed we need to create a nasty,
> > festering
> > > sore that irritates the open-source community into action.
> > >
> > > Moving the Conversation Forward
> > >
> > > Many people will likely hate my promotion of Flash for
> > learning
> > > activities. It's OK if you hate me and Flash. I do hope you
> > recognize
> > > that we need a more developer-centric activity framework
> > that uses web
> > > technologies.
> > >
> > > I have a lot more to write about Nepal's experiences
> > developing
> > > learning activities and my ideas on Convention over
> > Configuration in
> > > sugar activities. I will save those for another day.
> > >
> > >
> > > --
> > > Bryan W. Berry
> > > Technology Director
> > > OLE Nepal, http://www.olenepal.org
> > >
> > > _______________________________________________
> > > IAEP -- It's An Education Project (not a laptop project!)
> > > IAEP at lists.sugarlabs.org
> > > http://lists.sugarlabs.org/listinfo/iaep
> > >
> > _______________________________________________
> > Sugar-devel mailing list
> > Sugar-devel at lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/sugar-devel
> >
> --
> Bryan W. Berry
> Technology Director
> OLE Nepal, http://www.olenepal.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090102/ad693221/attachment-0001.htm
From bryan at olenepal.org Fri Jan 2 15:10:09 2009
From: bryan at olenepal.org (Bryan Berry)
Date: Fri, 02 Jan 2009 12:10:09 -0800
Subject: [Sugar-devel] [IAEP] How to Make Activity Designers Happy ,
Parts I and II
In-Reply-To: <7087c32a0901021154r506f1f76k8b61cb0a68b2c672@mail.gmail.com>
References: <1230861040.17108.4.camel__8009.18864920295$1230861178$gmane$org@hitman>
<1230874359.17108.16.camel@hitman>
<1230912293.17108.41.camel@hitman>
<1230923827.17108.65.camel@hitman>
<7087c32a0901021154r506f1f76k8b61cb0a68b2c672@mail.gmail.com>
Message-ID: <1230927010.17108.103.camel@hitman>
On Fri, 2009-01-02 at 14:54 -0500, Wade Brainerd wrote:
I don't understand the construing of constructionism with "exclusively
> high-level math and science" and I don't quite what you mean
> by
> "foundational skills". I don't think anyone would argue that
> we don't
> want numeracy and literacy to be "low shelf" tools in every
> child's
> repertoire, but what does this have to do with the other
> topics in
> this thread?
>
> I read this as saying that the constructivist activities that have
> been developed *so far* by programmers in developed countries tend to
> focus on high level concept learning rather than foundational skills.
> And I agree with this statement.
> I'm currently working on Typing Turtle, a typing trainer for the XO.
> One could say "they have Write and Chat, they will learn how to type"
> - that would be a constructivist approach. I feel like there is a
> need for more focused training of fundamental 'low shelf' skills,
> that's why I'm working on that particular activity.
The Typing Turtle will be immensely useful and immensely popular in
Nepal. A typing tutor is one of the most frequently requested programs
by the Nepali kids and teachers alike. Thanks alot to Wade for working
on it.
While no one is arguing that basic literacy and numeracy are less
important, there are far fewer activities addressing them. Most focus on
higher-level skills. Sometimes I feel there is an attitude that kids
will "just learn" counting or reading by using Etoys or another program.
I don't believe that will happen for a lot of kids.
Also, too often we focus on empowering the smart kids in the class. This
project is about mass education. Helping the vast majority of kids is
the real point, not just the superlative ones.
Case in point, some of the sharper kids at Bishwamitra school think a
lot of the E-Paath math activities are lame and boring. The academically
weaker kids love them and do them over and over until they master them.
These are 6th graders who until recently couldn't count properly. Those
students initially had trouble w/ some of our math problems for grade
2.
Some kids may learn basic math and reading so they can go straight to
using TurtleArt. They may hate simple math and language lessons. A lot
of kids won't be able to go straight TurtleArt. We need to think about
them as well.
--
Bryan W. Berry
Technology Director
OLE Nepal, http://www.olenepal.org
From walter.bender at gmail.com Fri Jan 2 15:18:59 2009
From: walter.bender at gmail.com (Walter Bender)
Date: Fri, 2 Jan 2009 15:18:59 -0500
Subject: [Sugar-devel] [IAEP] How to Make Activity Designers Happy ,
Parts I and II
In-Reply-To: <1230927010.17108.103.camel@hitman>
References: <1230861040.17108.4.camel__8009.18864920295$1230861178$gmane$org@hitman>
<1230874359.17108.16.camel@hitman>
<1230912293.17108.41.camel@hitman>
<1230923827.17108.65.camel@hitman>
<7087c32a0901021154r506f1f76k8b61cb0a68b2c672@mail.gmail.com>
<1230927010.17108.103.camel@hitman>
Message-ID:
On Fri, Jan 2, 2009 at 3:10 PM, Bryan Berry wrote:
> On Fri, 2009-01-02 at 14:54 -0500, Wade Brainerd wrote:
>
> I don't understand the construing of constructionism with "exclusively
>> high-level math and science" and I don't quite what you mean
>> by
>> "foundational skills". I don't think anyone would argue that
>> we don't
>> want numeracy and literacy to be "low shelf" tools in every
>> child's
>> repertoire, but what does this have to do with the other
>> topics in
>> this thread?
>>
>> I read this as saying that the constructivist activities that have
>> been developed *so far* by programmers in developed countries tend to
>> focus on high level concept learning rather than foundational skills.
>> And I agree with this statement.
>> I'm currently working on Typing Turtle, a typing trainer for the XO.
>> One could say "they have Write and Chat, they will learn how to type"
>> - that would be a constructivist approach. I feel like there is a
>> need for more focused training of fundamental 'low shelf' skills,
>> that's why I'm working on that particular activity.
>
> The Typing Turtle will be immensely useful and immensely popular in
> Nepal. A typing tutor is one of the most frequently requested programs
> by the Nepali kids and teachers alike. Thanks alot to Wade for working
> on it.
>
> While no one is arguing that basic literacy and numeracy are less
> important, there are far fewer activities addressing them. Most focus on
> higher-level skills. Sometimes I feel there is an attitude that kids
> will "just learn" counting or reading by using Etoys or another program.
> I don't believe that will happen for a lot of kids.
>
> Also, too often we focus on empowering the smart kids in the class. This
> project is about mass education. Helping the vast majority of kids is
> the real point, not just the superlative ones.
>
> Case in point, some of the sharper kids at Bishwamitra school think a
> lot of the E-Paath math activities are lame and boring. The academically
> weaker kids love them and do them over and over until they master them.
> These are 6th graders who until recently couldn't count properly. Those
> students initially had trouble w/ some of our math problems for grade
> 2.
>
> Some kids may learn basic math and reading so they can go straight to
> using TurtleArt. They may hate simple math and language lessons. A lot
> of kids won't be able to go straight TurtleArt. We need to think about
> them as well.
>
>
> --
> Bryan W. Berry
> Technology Director
> OLE Nepal, http://www.olenepal.org
>
>
I think we have consensus on three issues:
(1) We should try to support better integration of more development
environments into Sugar (e.g., cookbook Flash and Javascript support
of the Journal);
(2) We should encourage Activity developers (regardless of their
choice of development environment) to avoid extensive use of
drag-and-drop (I'll try to eat my own dogfood with TurtleArt);
(3) We need lots more Activities.
-walter
--
Walter Bender
Sugar Labs
http://www.sugarlabs.org
From bryan at olenepal.org Fri Jan 2 15:22:21 2009
From: bryan at olenepal.org (Bryan Berry)
Date: Fri, 02 Jan 2009 12:22:21 -0800
Subject: [Sugar-devel] [IAEP] How to Make Activity Designers Happy ,
Parts I and II
In-Reply-To:
References: <1230861040.17108.4.camel__8009.18864920295$1230861178$gmane$org@hitman>
<1230874359.17108.16.camel@hitman>
<1230912293.17108.41.camel@hitman>
<1230923827.17108.65.camel@hitman>
<7087c32a0901021154r506f1f76k8b61cb0a68b2c672@mail.gmail.com>
<1230927010.17108.103.camel@hitman>
Message-ID: <1230927741.17108.105.camel@hitman>
On Fri, 2009-01-02 at 15:18 -0500, Walter Bender wrote:
> I think we have consensus on three issues:
>
> (1) We should try to support better integration of more development
> environments into Sugar (e.g., cookbook Flash and Javascript support
> of the Journal);
> (2) We should encourage Activity developers (regardless of their
> choice of development environment) to avoid extensive use of
> drag-and-drop (I'll try to eat my own dogfood with TurtleArt);
> (3) We need lots more Activities.
>
> -walter
+1
--
Bryan W. Berry
Technology Director
OLE Nepal, http://www.olenepal.org
From bryan at olenepal.org Fri Jan 2 15:25:13 2009
From: bryan at olenepal.org (Bryan Berry)
Date: Fri, 02 Jan 2009 12:25:13 -0800
Subject: [Sugar-devel] [IAEP] How to Make Activity Designers Happy ,
Parts I and II
In-Reply-To:
References: <1230861040.17108.4.camel__8009.18864920295$1230861178$gmane$org@hitman>
<1230874359.17108.16.camel@hitman>
<1230912293.17108.41.camel@hitman>
<1230923827.17108.65.camel@hitman>
<7087c32a0901021154r506f1f76k8b61cb0a68b2c672@mail.gmail.com>
<1230927010.17108.103.camel@hitman>
Message-ID: <1230927913.17108.110.camel@hitman>
On Fri, 2009-01-02 at 15:18 -0500, Walter Bender wrote:
> (3) We need lots more Activities.
While there is consensus on this point, there is not consensus on the
best way to get a lot more Activities. That is, pulling a lot more
developers into building learning activities that run on Sugar.
--
Bryan W. Berry
Technology Director
OLE Nepal, http://www.olenepal.org
From wadetb at gmail.com Fri Jan 2 15:49:28 2009
From: wadetb at gmail.com (Wade Brainerd)
Date: Fri, 2 Jan 2009 15:49:28 -0500
Subject: [Sugar-devel] [IAEP] How to Make Activity Designers Happy ,
Parts I and II
In-Reply-To: <1230927913.17108.110.camel@hitman>
References: <1230861040.17108.4.camel__8009.18864920295$1230861178$gmane$org@hitman>
<1230912293.17108.41.camel@hitman>
<1230923827.17108.65.camel@hitman>
<7087c32a0901021154r506f1f76k8b61cb0a68b2c672@mail.gmail.com>
<1230927010.17108.103.camel@hitman>
<1230927913.17108.110.camel@hitman>
Message-ID: <7087c32a0901021249x42501d6eu79a5974439418861@mail.gmail.com>
On Fri, Jan 2, 2009 at 3:25 PM, Bryan Berry wrote:
> On Fri, 2009-01-02 at 15:18 -0500, Walter Bender wrote:
>
> > (3) We need lots more Activities.
>
> While there is consensus on this point, there is not consensus on the
> best way to get a lot more Activities. That is, pulling a lot more
> developers into building learning activities that run on Sugar.
There is a related point regarding Sugar idealism. Sugar was designed with
a very specific notion of what an activity: collaborative, constructivist,
stores in the Journal, view source, written in PyGTK using the supplied
frameworks.
The current inability to run Flash, Javascript or even GTK programs under
Sugar is linked to this initial choice.
More recently, a consensus seems to have developed that it is worthwhile to
include less "ideal" activities, in the name of having those activities at
all.
I think it is worth recognizing this change so as to encourage related
development efforts.
-Wade
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090102/c1595b69/attachment.htm
From michael at laptop.org Fri Jan 2 15:52:51 2009
From: michael at laptop.org (Michael Stone)
Date: Fri, 2 Jan 2009 15:52:51 -0500
Subject: [Sugar-devel] [IAEP] How to Make Activity Designers Happy ,
Parts I and II
In-Reply-To: <1230927913.17108.110.camel@hitman>
References: <1230874359.17108.16.camel@hitman>
<1230912293.17108.41.camel@hitman>
<1230923827.17108.65.camel@hitman>
<7087c32a0901021154r506f1f76k8b61cb0a68b2c672@mail.gmail.com>
<1230927010.17108.103.camel@hitman>
<1230927913.17108.110.camel@hitman>
Message-ID: <20090102205251.GG3164@didacte.laptop.org>
On Fri, Jan 02, 2009 at 12:25:13PM -0800, Bryan Berry wrote:
>On Fri, 2009-01-02 at 15:18 -0500, Walter Bender wrote:
>
>> (3) We need lots more Activities.
>
>While there is consensus on this point, there is not consensus on the
>best way to get a lot more Activities. That is, pulling a lot more
>developers into building learning activities that run on Sugar.
I see some orthogonal proposals at work:
a) supply better compatibility with existing X11 apps.
b) offer genuine support for popular software platforms (e.g. flash
and java?) even on space-constrained hardware platforms like the
XO.
c) catalyze the creation and improvement of free authoring and
remixing environments for popular mime-types uncovered by existing
free offerings or the available environments are unusable on the
available hardware
Consequently, it seems to me that the most useful political discussion
we can have now is over how to work through the obvious conflict between
the "libre" folks and the "usability" folks. Thoughts?
Michael
P.S. - (By all means, please continue the practical idea-by-idea
brainstorming occuring on Tomeu's thread in parallel with this
meta-thread!)
From walter.bender at gmail.com Fri Jan 2 16:01:34 2009
From: walter.bender at gmail.com (Walter Bender)
Date: Fri, 2 Jan 2009 16:01:34 -0500
Subject: [Sugar-devel] [IAEP] How to Make Activity Designers Happy ,
Parts I and II
In-Reply-To: <20090102205251.GG3164@didacte.laptop.org>
References: <1230874359.17108.16.camel@hitman>
<1230912293.17108.41.camel@hitman>
<1230923827.17108.65.camel@hitman>
<7087c32a0901021154r506f1f76k8b61cb0a68b2c672@mail.gmail.com>
<1230927010.17108.103.camel@hitman>
<1230927913.17108.110.camel@hitman>
<20090102205251.GG3164@didacte.laptop.org>
Message-ID:
On Fri, Jan 2, 2009 at 3:52 PM, Michael Stone wrote:
> On Fri, Jan 02, 2009 at 12:25:13PM -0800, Bryan Berry wrote:
>>
>> On Fri, 2009-01-02 at 15:18 -0500, Walter Bender wrote:
>>
>>> (3) We need lots more Activities.
>>
>> While there is consensus on this point, there is not consensus on the
>> best way to get a lot more Activities. That is, pulling a lot more
>> developers into building learning activities that run on Sugar.
>
> I see some orthogonal proposals at work:
> a) supply better compatibility with existing X11 apps.
>
> b) offer genuine support for popular software platforms (e.g. flash
> and java?) even on space-constrained hardware platforms like the
> XO.
>
> c) catalyze the creation and improvement of free authoring and
> remixing environments for popular mime-types uncovered by existing
> free offerings or the available environments are unusable on the
> available hardware
>
> Consequently, it seems to me that the most useful political discussion
> we can have now is over how to work through the obvious conflict between
> the "libre" folks and the "usability" folks. Thoughts?
I guess I am slow. Can you spell out this "obvious" conflict in the
context of this discussion?
>
> Michael
>
> P.S. - (By all means, please continue the practical idea-by-idea
> brainstorming occuring on Tomeu's thread in parallel with this
> meta-thread!)
>
-walter
--
Walter Bender
Sugar Labs
http://www.sugarlabs.org
From bryan at olenepal.org Fri Jan 2 17:28:16 2009
From: bryan at olenepal.org (Bryan Berry)
Date: Fri, 02 Jan 2009 14:28:16 -0800
Subject: [Sugar-devel] web-based activity prototypes
In-Reply-To: <242851610901021018r4c84d249r8b348dc126c4bbe9@mail.gmail.com>
References: <242851610901021018r4c84d249r8b348dc126c4bbe9@mail.gmail.com>
Message-ID: <1230935296.32208.8.camel@hitman>
You can view the flash-based activities OLE Nepal is developing in your
regular web browser. We have them stored in our online E-LIbrary
http://www.pustakalaya.org/external-content/static/epaath/E-Paath-2.activity/activity/Activity/MenuStage.html
1) Click on a grade in the upper-lefthand corner and the subject on
right hand pane. then the weeks appear
2) Click on a Week and the activities should appear
3) The activity launches in a separate FF window
4) Click the text in the middle to start the lesson
--
Bryan W. Berry
Technology Director
OLE Nepal, http://www.olenepal.org
From michael at laptop.org Fri Jan 2 17:52:06 2009
From: michael at laptop.org (Michael Stone)
Date: Fri, 2 Jan 2009 17:52:06 -0500
Subject: [Sugar-devel] [IAEP] How to Make Activity Designers Happy ,
Parts I and II
In-Reply-To:
References: <1230912293.17108.41.camel@hitman>
<1230923827.17108.65.camel@hitman>
<7087c32a0901021154r506f1f76k8b61cb0a68b2c672@mail.gmail.com>
<1230927010.17108.103.camel@hitman>
<1230927913.17108.110.camel@hitman>
<20090102205251.GG3164@didacte.laptop.org>
Message-ID: <20090102225206.GH3164@didacte.laptop.org>
On Fri, Jan 02, 2009 at 04:01:34PM -0500, Walter Bender wrote:
>On Fri, Jan 2, 2009 at 3:52 PM, Michael Stone wrote:
>> On Fri, Jan 02, 2009 at 12:25:13PM -0800, Bryan Berry wrote:
>>>
>>> On Fri, 2009-01-02 at 15:18 -0500, Walter Bender wrote:
>>>
>>>> (3) We need lots more Activities.
>>>
>>> While there is consensus on this point, there is not consensus on the
>>> best way to get a lot more Activities. That is, pulling a lot more
>>> developers into building learning activities that run on Sugar.
>>
>> I see some orthogonal proposals at work:
>> a) supply better compatibility with existing X11 apps.
>>
>> b) offer genuine support for popular software platforms (e.g. flash
>> and java?) even on space-constrained hardware platforms like the
>> XO.
>>
>> c) catalyze the creation and improvement of free authoring and
>> remixing environments for popular mime-types uncovered by existing
>> free offerings or the available environments are unusable on the
>> available hardware
>>
>> Consequently, it seems to me that the most useful political discussion
>> we can have now is over how to work through the obvious conflict between
>> the "libre" folks and the "usability" folks. Thoughts?
>
>I guess I am slow. Can you spell out this "obvious" conflict in the
>context of this discussion?
Sure. Basically, I think we're in an iterated prisoner's dilemma
situation. The dilemma arises from the facts that
a) Sugar exists in both one global and myriad local environments and
b) Pairs of people frequently have access to resources which they are
unable to share; e.g. expertise, time, or non-redistributable code.
Fact (a) affords us a range of strategies during each iteration varying
between the hypothetical extremes of "acting locally" and "acting
globally".
Fact (b) means that acting locally frequently affords us payoffs which
cannot be shared with our partners in the game or which are actively
detrimental to those other players.
The situation is iterated because we seem to have to make decisions
along these lines every month or so.
The connection to the "libre" vs "usability" dichotomy that I mentioned
above is that I see the "libre" folks as asking all players to choose
strategies which optimize "global" payoffs at the (great) expense of
"local" payoffs; and vice-versa for the "usability" folks.
Does this explanation help clarify things for you? Would a different
metaphor be more helpful?
Regards,
Michael
From walter.bender at gmail.com Fri Jan 2 18:12:40 2009
From: walter.bender at gmail.com (Walter Bender)
Date: Fri, 2 Jan 2009 18:12:40 -0500
Subject: [Sugar-devel] [IAEP] How to Make Activity Designers Happy ,
Parts I and II
In-Reply-To: <20090102225206.GH3164@didacte.laptop.org>
References: <1230912293.17108.41.camel@hitman>
<1230923827.17108.65.camel@hitman>
<7087c32a0901021154r506f1f76k8b61cb0a68b2c672@mail.gmail.com>
<1230927010.17108.103.camel@hitman>
<1230927913.17108.110.camel@hitman>
<20090102205251.GG3164@didacte.laptop.org>
<20090102225206.GH3164@didacte.laptop.org>
Message-ID:
On Fri, Jan 2, 2009 at 5:52 PM, Michael Stone wrote:
> On Fri, Jan 02, 2009 at 04:01:34PM -0500, Walter Bender wrote:
>>
>> On Fri, Jan 2, 2009 at 3:52 PM, Michael Stone wrote:
>>>
>>> On Fri, Jan 02, 2009 at 12:25:13PM -0800, Bryan Berry wrote:
>>>>
>>>> On Fri, 2009-01-02 at 15:18 -0500, Walter Bender wrote:
>>>>
>>>>> (3) We need lots more Activities.
>>>>
>>>> While there is consensus on this point, there is not consensus on the
>>>> best way to get a lot more Activities. That is, pulling a lot more
>>>> developers into building learning activities that run on Sugar.
>>>
>>> I see some orthogonal proposals at work:
>>> a) supply better compatibility with existing X11 apps.
>>>
>>> b) offer genuine support for popular software platforms (e.g. flash
>>> and java?) even on space-constrained hardware platforms like the
>>> XO.
>>>
>>> c) catalyze the creation and improvement of free authoring and
>>> remixing environments for popular mime-types uncovered by existing
>>> free offerings or the available environments are unusable on the
>>> available hardware
>>>
>>> Consequently, it seems to me that the most useful political discussion
>>> we can have now is over how to work through the obvious conflict between
>>> the "libre" folks and the "usability" folks. Thoughts?
>>
>> I guess I am slow. Can you spell out this "obvious" conflict in the
>> context of this discussion?
>
> Sure. Basically, I think we're in an iterated prisoner's dilemma
> situation. The dilemma arises from the facts that
> a) Sugar exists in both one global and myriad local environments and
>
> b) Pairs of people frequently have access to resources which they are
> unable to share; e.g. expertise, time, or non-redistributable code.
>
> Fact (a) affords us a range of strategies during each iteration varying
> between the hypothetical extremes of "acting locally" and "acting
> globally".
>
> Fact (b) means that acting locally frequently affords us payoffs which
> cannot be shared with our partners in the game or which are actively
> detrimental to those other players.
>
> The situation is iterated because we seem to have to make decisions
> along these lines every month or so.
>
> The connection to the "libre" vs "usability" dichotomy that I mentioned
> above is that I see the "libre" folks as asking all players to choose
> strategies which optimize "global" payoffs at the (great) expense of
> "local" payoffs; and vice-versa for the "usability" folks.
>
> Does this explanation help clarify things for you? Would a different
> metaphor be more helpful?
>
> Regards,
>
> Michael
>
Thanks. This is helpful.
But I wonder (1) if these sort of dichotomies occur "frequently" and
(2) to what extent they incur "great" expense. Presumably the 2007
decision to not aggressively pursue Flash support on the laptop is an
example of a choice in the "libre" category? (Although, at the time,
the decision was driven as much by some pragmatic integration concerns
as by ideology.) And the decision to use a GNU/Linux distribution as
oppose to XP (we would have had to have designed a different laptop
had we gone down that path). But this is water that is over the dam,
not a recurring theme. There have been local decisions that have
incurred "expense", e.g. Uruguay made changes to the base image (not
many that are relevant to Sugar) due to the needs of their
deployments. But this had nothing to do with "libre" vs. "usability."
Bryan's point about drag-and-drop and the lack of applications
addressing "fundamentals" don't seem to be correlated to this
dichotomy. Can you please cite a few examples to help ground me
further?
-walter
--
Walter Bender
Sugar Labs
http://www.sugarlabs.org
From sascha-ml-ui-sugar-devel at silbe.org Fri Jan 2 18:55:06 2009
From: sascha-ml-ui-sugar-devel at silbe.org (Sascha Silbe)
Date: Sat, 3 Jan 2009 00:55:06 +0100
Subject: [Sugar-devel] Teaching typing and basic math on the XO (was: Re:
[IAEP] How to Make Activity Designers Happy , Parts I and II)
In-Reply-To: <1230927010.17108.103.camel@hitman>
References: <1230861040.17108.4.camel__8009.18864920295$1230861178$gmane$org@hitman>
<1230874359.17108.16.camel@hitman>
<1230912293.17108.41.camel@hitman>
<1230923827.17108.65.camel@hitman>
<7087c32a0901021154r506f1f76k8b61cb0a68b2c672@mail.gmail.com>
<1230927010.17108.103.camel@hitman>
Message-ID: <20090102235506.GA23251@twin.sascha.silbe.org>
On Fri, Jan 02, 2009 at 12:10:09PM -0800, Bryan Berry wrote:
> The Typing Turtle will be immensely useful and immensely popular in
> Nepal. A typing tutor is one of the most frequently requested programs
> by the Nepali kids and teachers alike. Thanks alot to Wade for working
> on it.
Have you tried TuxType/TuxTyping [1] and (a recent version of) TuxMath?
There's no XO bundle for them yet, but if they fit your needs, you might
try asking Albert Calahan. He seems to have done the TuxPaint [2] bundle
[3,5] (all three programs are from the same project - Tux4Kids [4]).
[1] http://tuxtype.sourceforge.net/
[2] http://www.tuxpaint.org/
[3] http://wiki.laptop.org/go/Tux_Paint
[4] http://tux4kids.alioth.debian.org/
[5] http://wiki.laptop.org/go/Activities/All
CU Sascha
--
http://sascha.silbe.org/
http://www.infra-silbe.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: Digital signature
Url : http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090103/109297e4/attachment.pgp
From wadetb at gmail.com Fri Jan 2 19:20:05 2009
From: wadetb at gmail.com (Wade Brainerd)
Date: Fri, 2 Jan 2009 19:20:05 -0500
Subject: [Sugar-devel] Teaching typing and basic math on the XO (was:
Re: [IAEP] How to Make Activity Designers Happy , Parts I and II)
In-Reply-To: <20090102235506.GA23251@twin.sascha.silbe.org>
References: <1230861040.17108.4.camel__8009.18864920295$1230861178$gmane$org@hitman>
<1230874359.17108.16.camel@hitman>
<1230912293.17108.41.camel@hitman>
<1230923827.17108.65.camel@hitman>
<7087c32a0901021154r506f1f76k8b61cb0a68b2c672@mail.gmail.com>
<1230927010.17108.103.camel@hitman>
<20090102235506.GA23251@twin.sascha.silbe.org>
Message-ID: <7087c32a0901021620t76f42fcele8c97ed01cedc3d8@mail.gmail.com>
If you have used TuxType, you will know that it's a simplistic typing
*practice game* and in no way teaches the user how to type.
That said, there are typing programs out there that could work. I just
wanted to make a nice one for Sugar.
-Wade
On Fri, Jan 2, 2009 at 6:55 PM, Sascha Silbe <
sascha-ml-ui-sugar-devel at silbe.org> wrote:
> On Fri, Jan 02, 2009 at 12:10:09PM -0800, Bryan Berry wrote:
>
> The Typing Turtle will be immensely useful and immensely popular in
>> Nepal. A typing tutor is one of the most frequently requested programs
>> by the Nepali kids and teachers alike. Thanks alot to Wade for working
>> on it.
>>
> Have you tried TuxType/TuxTyping [1] and (a recent version of) TuxMath?
> There's no XO bundle for them yet, but if they fit your needs, you might
> try asking Albert Calahan. He seems to have done the TuxPaint [2] bundle
> [3,5] (all three programs are from the same project - Tux4Kids [4]).
>
>
> [1] http://tuxtype.sourceforge.net/
> [2] http://www.tuxpaint.org/
> [3] http://wiki.laptop.org/go/Tux_Paint
> [4] http://tux4kids.alioth.debian.org/
> [5] http://wiki.laptop.org/go/Activities/All
>
> CU Sascha
>
> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iQEVAwUBSV6pWrpz82VMF3DaAQLL0gf/c8N5HvCAiuM8vNC9TIn5rb5afUtJCb2M
> pzWMSDDBQYpRQniwi04qgS7exVh0OlYFficKrrZni9dAEVL582zRGzCHVmP7RIda
> 5PLpA5UOcgQIjGvoyeiBO+yhdx540kmsPU0UWzE7ZQEdAwdJUnlgF5aB/L0pT8H+
> /0hdMbR1uHrServp6EPikvmkq95lWTf78YR3cLcKjmBF7gvxHNVv5mtFEb5HvbfG
> SF5lmxNSFWojx7LrHYYA7EArO7vMDvK25sYTofBTZ32cml3egGH6SqPgRW7MiUGj
> nRmjfYba2Z9FE9AhQsyUkUZUNyqT6sbcrff2zMbJLW5/LIbfQ5gXfw==
> =cZiZ
> -----END PGP SIGNATURE-----
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090102/f05e768a/attachment.htm
From michael at laptop.org Fri Jan 2 19:25:19 2009
From: michael at laptop.org (Michael Stone)
Date: Fri, 2 Jan 2009 19:25:19 -0500
Subject: [Sugar-devel] [IAEP] How to Make Activity Designers Happy ,
Parts I and II
In-Reply-To:
References: <1230923827.17108.65.camel@hitman>
<7087c32a0901021154r506f1f76k8b61cb0a68b2c672@mail.gmail.com>
<1230927010.17108.103.camel@hitman>
<1230927913.17108.110.camel@hitman>
<20090102205251.GG3164@didacte.laptop.org>
<20090102225206.GH3164@didacte.laptop.org>
Message-ID: <20090103002519.GI3164@didacte.laptop.org>
On Fri, Jan 02, 2009 at 06:12:40PM -0500, Walter Bender wrote:
> Can you please cite a few examples to help ground me further?
Let's try:
* the Etoys/Debian fight?
* the F6/F7 timeframe Java fight?
* the Debian/Fedora fight? (and the Ubuntu/Debian fight?)
* the activity packaging formats fight?
* the initscripts fight?
* the vserver fight?
* the libertas fight(s)?
* the Bitfrost/____ fight?
* the Journal/file manager fight?
* the livecd-tools / pilgrim+puritan fight?
* the stock vs. patched kernel fight?
* the UY, ET, and NE modification fights?
* deciding how and where to seek donations to OLPC (or alternately,
to market and sell XOs, depending on your perspective).
>(2) to what extent they incur "great" expense.
I agree that it's hard to measure. (I still think it's worth trying to
think about.) The most significant factor seems to be whether and how
you count opportunity costs.
Three random examples:
* The early Smalltalk vs. Python arguments
* Bryan's point about choosing a PyGTK stack vs. a Javascript-ish stack
* Fedora vs. Debian
> Presumably the 2007 decision to not aggressively pursue Flash support
> on the laptop is an example of a choice in the "libre" category?
I'm counting it as such.
> (Although, at the time, the decision was driven as much by some
> pragmatic integration concerns as by ideology.)
As with some current debates about key autonomy, the ideological battle
strongly influences our willingness to do the implementation/integration
work.
>And the decision to use a GNU/Linux distribution as oppose to XP (we
>would have had to have designed a different laptop had we gone down
>that path).
Yes.
>But this is water that is over the dam, not a recurring theme.
It seems to me to be a recurring theme for OLPC; perhaps Sugar Labs will
do better.
> There have been local decisions that have incurred "expense", e.g.
> Uruguay made changes to the base image (not many that are relevant to
> Sugar) due to the needs of their deployments.
As I see it, it had everything to do with exploiting local opportunities
vs. "acting globally". "Libre"-ness is just one reason that a _few_
people (who are active here) seem to put forward for why we _shouldn't_
exploit those purely local opportunities.
> But this had nothing to do with "libre" vs. "usability."
"libre"-prizing and "usability"-prizing are just contingent attitudes
which seem to me to bias people towards optimizing for specific locales
(including, occasionally, the global one). Lots of other contingent
attitudes have the same effect. I brought up "libre" and "usability"
because they seemed to me to be prominent in the current thread.
>Bryan's point about drag-and-drop and the lack of applications
>addressing "fundamentals" don't seem to be correlated to this
>dichotomy.
Correct -- it's an interesting and worthwhile but unrelated criticism of
the status quo.
Michael
P.S. - Please let me know if you'd like to me to try to analyze some of
the examples I suggested in more detail, e.g. if it's unclear what I
mean, why I think they're relevant, or if you're bothered by the fact
that they can be interpreted in several valid ways.
From wadetb at gmail.com Fri Jan 2 20:34:43 2009
From: wadetb at gmail.com (Wade Brainerd)
Date: Fri, 2 Jan 2009 20:34:43 -0500
Subject: [Sugar-devel] [IAEP] How to Make Activity Designers Happy ,
Parts I and II
In-Reply-To: <20090103002519.GI3164@didacte.laptop.org>
References: <1230923827.17108.65.camel@hitman>
<7087c32a0901021154r506f1f76k8b61cb0a68b2c672@mail.gmail.com>
<1230927010.17108.103.camel@hitman>
<1230927913.17108.110.camel@hitman>
<20090102205251.GG3164@didacte.laptop.org>
<20090102225206.GH3164@didacte.laptop.org>
<20090103002519.GI3164@didacte.laptop.org>
Message-ID: <7087c32a0901021734h595ea865we37b5eaf93936ff@mail.gmail.com>
On Fri, Jan 2, 2009 at 7:25 PM, Michael Stone wrote:
> On Fri, Jan 02, 2009 at 06:12:40PM -0500, Walter Bender wrote:
> > Can you please cite a few examples to help ground me further?
>
> Let's try:
>
> * the Etoys/Debian fight?
> * the F6/F7 timeframe Java fight?
> * the Debian/Fedora fight? (and the Ubuntu/Debian fight?)
> * the activity packaging formats fight?
> * the initscripts fight?
> * the vserver fight?
> * the libertas fight(s)?
> * the Bitfrost/____ fight?
> * the Journal/file manager fight?
> * the livecd-tools / pilgrim+puritan fight?
> * the stock vs. patched kernel fight?
> * the UY, ET, and NE modification fights?
> * deciding how and where to seek donations to OLPC (or alternately,
> to market and sell XOs, depending on your perspective).
Not knowing all the gossip, a lot of these seem more like "conservative" vs
"exciting" decisions rather than "libre" vs "usability" or "global" vs
"local".
Programmer/Manager A: Let's do crazy idea X, it will solve A, B and C and
will be simple to implement!
Programmer/Manager B: You have no idea what what problems will really arise
with X. Let's just stick with what works, Y.
This judgment process is a natural part of software development.
As a fun exercise, I personally come down at: Etoys, missed that one,
Debian, something other than xo bundles, custom initscripts!!, KISS,
libertas FTW, the best security is a reflash usb key and backup, both,
probably livecd-tools, PATCHED, let them do whatever they need to, market
away but avoid sponsors.
Cheers,
-Wade
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090102/ee9c71b9/attachment.htm
From wadetb at gmail.com Fri Jan 2 20:42:21 2009
From: wadetb at gmail.com (Wade Brainerd)
Date: Fri, 2 Jan 2009 20:42:21 -0500
Subject: [Sugar-devel] Teaching typing and basic math on the XO
In-Reply-To: <20090103003834.GB23251@twin.sascha.silbe.org>
References: <1230874359.17108.16.camel@hitman>
<1230912293.17108.41.camel@hitman>
<1230923827.17108.65.camel@hitman>
<7087c32a0901021154r506f1f76k8b61cb0a68b2c672@mail.gmail.com>
<1230927010.17108.103.camel@hitman>
<20090102235506.GA23251@twin.sascha.silbe.org>
<7087c32a0901021620t76f42fcele8c97ed01cedc3d8@mail.gmail.com>
<20090103003834.GB23251@twin.sascha.silbe.org>
Message-ID: <7087c32a0901021742i49aaa97rd70d2a8992e8b217@mail.gmail.com>
I'm following the format used by programs like MicroType and Mavis Beacon
Teaches Typing (what I personally learned on). Both have demo versions for
Windows available.
TT will be simple compared with these programs, but they are the general
template.
We are working towards an alpha in early January.. When it's ready I will
announce it on the sugar list.
Cheers,
Wade
On Fri, Jan 2, 2009 at 7:38 PM, Sascha Silbe <
sascha-ml-ui-sugar-sugar at silbe.org> wrote:
> On Fri, Jan 02, 2009 at 07:20:05PM -0500, Wade Brainerd wrote:
>
> If you have used TuxType, you will know that it's a simplistic typing
>> *practice game* and in no way teaches the user how to type.
>>
> I thought that's what you're looking for. How do you imagine a "typing
> teaching activity" to work?
> What does the "Typing Turtle" activity that was mentioned look like?
>
> CU Sascha
>
> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iQEVAwUBSV6zirpz82VMF3DaAQLpMwgArkQogjN/D+9IUvqvbHlXaduKF6UMaxfg
> JIfTIbdTccjCxuXzqMv90hrFCXEg1stiXqgaWjZpCX5JN+WjDkSQPYxY2oeQQOZj
> 0+TiYbsLwWFOUXPlJkfiJpKXVH+cOu0et5ZIqSPd84MyekxtGqCyb0sd/uKCcu09
> zr7Ri2ADoQoq1p1XI38m/IqCRyiDtpez9UX8AB2L48tDD15Yhlnh0QMy7EuhYMli
> ZhtW1Ng33pWV9diYkjawmD8vs+rniFtcXKW/IZG63LOV5UZ66eMEGx6CAKV9TXNp
> jOjPW9L5oUZLh0/Cb1hFvKYRzzDuLKijdNcvYWfRKw8Bv0MrkhmOAg==
> =7WVV
> -----END PGP SIGNATURE-----
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090102/17097bb9/attachment.htm
From echerlin at gmail.com Fri Jan 2 21:45:49 2009
From: echerlin at gmail.com (Edward Cherlin)
Date: Fri, 2 Jan 2009 18:45:49 -0800
Subject: [Sugar-devel] [IAEP] Sugar Digest 2008-12-29
In-Reply-To:
References:
Message-ID:
In addition to the essential ideas discussed below, we need to have a
discussion of skill, and the appropriate kinds of practice for
achieving it. We have ample proof that reading cannot be taught simply
as a classroom subject. Those who catch the reading bug, and read all
sorts of things that no teacher assigns, will be our best readers, and
in many cases our best writers. But we also need to practice the arts
of speaking and listening. We know that keyboarding is a skill where
drill is of value. We know that daily practice is essential for
developing musical skill (except in some cases of prodigies and
savants). We know that the best way to become fluent in a language is
to have people to talk with, so that the skills become habit rather
than knowledge. We know that calculation of various kinds can benefit
from drill.
But we cannot suppose that doing every possible drill in the best
possible way constitutes an education.
Also, when we speak of critical thinking, we need to introduce the
appropriate standards, and teach our students how to adhere to them,
and how to tell when somebody is failing to do that: logic and proof
in mathematics, the scientific method, rules of evidence in law, and
many others, to begin with, but also the deeper questions, how those
got to be the rules, and whether we can make further progress. The art
and logic of discovery, which is quite different from proof. Effective
methods of collaboration. And so on.
Earth Treasury and its partners propose to re-invent the textbook for
the one-to-one age, making use of all of these powerful ideas,
together with our current moderately powerful hardware and wonderful
but still preliminary software. We invite participation, discussion,
and criticism.
http://wiki.laptop.org/go/Creating_textbooks
On Mon, Dec 29, 2008 at 6:35 AM, Walter Bender wrote:
> As 2008 comes to an end, it gives me an excuse to do some reflecting
> on what we are doing as a project and foundation. Most of the
> following you've read before, but it is helpful?at least to me?to
> revisit these ideas periodically.
>
> The world faces many seemingly intractable problems: war, a faltering
> economy, an energy crisis, global climate change, to name just a few.
> My generation has failed to solve these problems. Our children will
> inherit them from us. But we can leave them something in addition: the
> means to become a generation of critical thinkers and problem-solvers.
> The investment that we can make on their behalf that will have the
> most return is learning. It has a bearing on all of the challenges we
> face and is essential if our children are to excel in an ever-changing
> world. Providing every child with the opportunity to learn learning
> will allow them both to achieve a clarity of purpose and to develop
> independent means towards their goals.
>
> What should children and learn and how should they learn it?
> Information is about nouns; learning is about verbs. Of course
> learners should have access to power ideas (I won't debate here which
> ones we should teach). But they should also engage in exploration and
> collaboration, appropriating knowledge while engaging in authentic,
> open-ended problem solving. This can be accomplished within a
> framework of accountability, one that complements rigorous national
> standards where learners engage in a process of reflection, public
> expression, and critique?a "portfolio" approach. What am I learning?
> How did I learn it? Why is it important? Can I teach it to others?
>
> We have some simple, universal points of leverage:
>
> * Everyone is a teacher and a learner.
> * Humans are social beings.
> * Humans are expressive.
>
> You learn through doing, so if you want to learn more, you want to do more.
>
> Love is a better master than duty?you want people to engage in things
> that are authentic to them, things that they love. Internal motivation
> almost always trumps external motivations.
>
> These ideas are not immiscible with current norms within schools, but
> too often we fall back on what we "know". I challenge you to think of
> a great learning moment in your life: was it sitting in a classroom,
> all eyes forward, listening to a lecture or was in when you were
> trying to solve a problem that was important to you?
>
> We know of no better tool for learning than a computer?it is a "thing
> to think with" when it is used as a means of knowledge creation.
> (Unfortunately, it is too often thought of and used as simply a
> mechanism for information retrieval and rote learning in our
> schools?the modern equivalent of the mimeograph machine, AKA the
> "purple" plague.)
>
> Three experiences can characterize a computer-enhanced learning platform:
>
> Sharing: The interface should always shows the presence of other
> learners. Collaboration is a first-order experience. Students and
> teachers dialog with each other, support each other, critique each
> other, and share ideas.
>
> Reflecting: A "Journal" should record each learner's activity. The
> Journal serves as a place for reflection and assessment of
> progress?the basis of a portfolio.
>
> Discovering: We can accommodate a wide variety of users, with
> different levels of skill in terms of reading, language, and different
> levels of experience with computing. It is easy to approach, yet it
> doesn't put an upper bound on personal expression. One should always
> be able to peel away layers and go deeper and deeper, with no
> restrictions. This allows the direct appropriation of ideas in
> whatever realm the learner is exploring: music, browsing, reading,
> writing, programming, or graphics. The student can always go further.
>
> These are the core ideas behind Sugar. By embodying these ideas
> directly into the affordances provided by the user interface, we can
> skew the odds that teachers and learners will engage in more than the
> accumulation and transfer of information.
>
> In Sugar, have in hand the tools to reinvent how computers are used
> for education. Collaboration, reflection, and discovery are readily
> integrated directly into the learning experience. Children and
> teachers have the opportunity to use computers on their own terms,
> reshape, reinvent, and reapply both software and content into powerful
> learning activities. Learning can be focused on sharing, criticism,
> and exploration. We have a lot of work ahead of us to refine these
> tools and to refine the practice around them, but we have a solid
> beginning.
>
> We can raise a generation of critical thinkers, armed with the
> complementary tools of science and the arts. (Relatively speaking, it
> is a trivial investment?probably less than the cost of a single
> "bridge to nowhere". All of the necessary tools are freely available
> under free software licenses. But we do need to invest in engaging
> teachers, parents, and children in learning learning.) So let's make
> it happen.
>
> ===Sugar Labs===
>
> Gary Martin has generated another SOM from the past week of discussion
> on the IAEP mailing list (Please see
> http://sugarlabs.org/go/Image:2008-December-20-26-som.jpg).
>
>
> Happy New Year.
>
> -walter
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
> _______________________________________________
> IAEP -- It's An Education Project (not a laptop project!)
> IAEP at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>
--
Silent Thunder (??/???????????????/????????????? ?) is my name
And Children are my nation.
The Cosmos is my dwelling place, The Truth my destination.
http://wiki.sugarlabs.org/go/User:Mokurai
From arjun at laptop.org Fri Jan 2 23:19:57 2009
From: arjun at laptop.org (Arjun Sarwal)
Date: Sat, 3 Jan 2009 09:49:57 +0530
Subject: [Sugar-devel] TA with sensors
In-Reply-To:
References:
Message-ID:
On Sat, Jan 3, 2009 at 1:18 AM, Walter Bender wrote:
> Thanks for this background.
>
> I think that the try/exception mechanism is adequate for our needs. It
> will be otherwise trivial for me to add the sensor features to the
> main branch of TA... I'll add it to the next release.
>
> I wonder if there is a mechanism we can call upon (Sugar should
> perhaps provide this) that will tell us that we are being sent to the
> background so that we can only reinitialize when we go away and come
> back? It seems that for every call to the sensor, it is a large
> overhead to incur...
>
There are signals in Sugar that are fired when an Activity becomes the
background Activity or foreground Activity (I've used these in Measure
code). It seems like a good idea to explore to keep the capture device
ON while TurtleArt is the active Activity and leave the audio device
when Activity is in background and then re-initialize it when
TurtleArt becomes the active Activity.
> -walter
>
> On Fri, Jan 2, 2009 at 2:25 PM, Arjun Sarwal wrote:
>> Hello Walter,
>>
>> Thank you for the new year wishes. Best wishes to you too for the new
>> year! (hope you received my card too)
>>
>> A few points regarding adding sensor support
>>
>> * Calls to Alsamixer to set the DC mode on/off will result in an
>> exception on one's normal laptop. This is because the DC mode controls
>> don't exist in the Alsamixer of a normal laptop (even sugar emulation
>> makes calls to the laptop's default alsamixer)
>>
>> * I had put in initializations before each call to the sensor because
>> - user may switch to another Activity in between a session of Turtle
>> Art -- the other Activity may use the laptop's sound device. The
>> other Activity may alter the sound device settings.
>> - unless a call for sensor input is being made, I didn't want to keep
>> the capture device active.
>> The capture device can be thought to be in a state of 'recording
>> sound' when one is getting sensor input data, hence only one
>> Activity/program can have access to it at one time.
>> However, any suggestions you may have on the above implementation
>> would be very welcome.
>>
>>
>> * If it helps, I am summarizing approximately the changes I made in
>> TurtleArt to add sensor support and some relevant lines to look at
>> within the TA with Sensors code that I had made for the earlier (non
>> SVG version of TAwithSensors):
>> Referring to the version of the online git tree ('Initial import')
>> (http://dev.laptop.org/git?p=users/arjs/TurtleArtwithSensors;a=tree;h=3f22f9f86d60f6160268c52009273eba82dba465;hb=3f22f9f86d60f6160268c52009273eba82dba465)
>>
>> - audiograb.py as an additional file was included completely
>> - talogo.py :
>> (note that lines 8 and 9 in this version of git tree would need to be
>> changed to
>> from numpy.oldnumeric import *
>> from numpy.fft import * )
>> lines 8,9,11,12 were added
>> lines 366 onwards till the end have been added
>> -tasetup.py: lines 47 to 51 to account for the additional sensor
>> blocks in the UI
>>
>> As you can see from the code of talogo.py , the approach involves a
>> lot of painful starting the whole gstreamer pipeline, getting one
>> sample then stopping the pipeline. An overkill for getting just one
>> sample, but there is no way unless python alsa audio is included in
>> the build system. The approach with python alsa audio is work in
>> progress here (
>> http://dev.laptop.org/git?p=users/arjs/TurtleArtwithSensors;a=tree )
>>
>> I want to work on incorporating sensor support into the SVG version of
>> TA that you have made, but my current day job isn't leaving me any
>> time these days to do anything else. I will get to it as soon as I get
>> the opportunity, but if in the meanwhile you get a chance to do it -
>> it'd be great.
>>
>> Please let me know if I can help further.
>>
>> Kind Regards
>> Arjun
>>
>> On Fri, Jan 2, 2009 at 3:18 AM, Walter Bender wrote:
>>>
>>> I've begun folding TA with sensors into TA. I use an exception to
>>> catch the calls to set DC Mode in Alsamixer, so it seems to run fine
>>> on my normal laptop using the mic input. But when I look at the logs,
>>> it seems that there is a lot of initialization that happens with every
>>> call to the sensor. Is that all necessary? Can we just check for
>>> changes after the first time?
>>>
>>> -walter
>>>
>>>
>>>
>>> # test to see if DC Mode is enabled
>>> try:
>>> self.dcmode = Mixer('DC Mode Enable')
>>> self.bias = Mixer('V_REFOUT Enable')
>>> self.has_dcmode = True
>>> except:
>>> print "DC Mode unavailable"
>>> self.has_dcmode = False
>>>
>>>
>>>
>>> Walter Bender
>>> Sugar Labs
>>> http://www.sugarlabs.org
>>
>>
>>
>> --
>> Arjun Sarwal
>>
>
>
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
>
From echerlin at gmail.com Sat Jan 3 01:49:19 2009
From: echerlin at gmail.com (Edward Cherlin)
Date: Fri, 2 Jan 2009 22:49:19 -0800
Subject: [Sugar-devel] Teaching typing and basic math on the XO (was:
Re: [IAEP] How to Make Activity Designers Happy , Parts I and II)
In-Reply-To: <7087c32a0901021620t76f42fcele8c97ed01cedc3d8@mail.gmail.com>
References: <1230861040.17108.4.camel__8009.18864920295$1230861178$gmane$org@hitman>
<1230912293.17108.41.camel@hitman>
<1230923827.17108.65.camel@hitman>
<7087c32a0901021154r506f1f76k8b61cb0a68b2c672@mail.gmail.com>
<1230927010.17108.103.camel@hitman>
<20090102235506.GA23251@twin.sascha.silbe.org>
<7087c32a0901021620t76f42fcele8c97ed01cedc3d8@mail.gmail.com>
Message-ID:
On Fri, Jan 2, 2009 at 4:20 PM, Wade Brainerd wrote:
> If you have used TuxType, you will know that it's a simplistic typing
> *practice game* and in no way teaches the user how to type.
>
> That said, there are typing programs out there that could work. I just
> wanted to make a nice one for Sugar.
Learning to type in Indic writing systems, including Devanagari for
Nepali, is much easier than learning any Latin-alphabet keyboard. It
took me a month to switch from QWERTY to Dvorak, but only two days to
be able to type in Sanskrit (though not as fast).
The consonants are laid out in a logical order based on the work of
the ancient Sanskrit grammarians, with each of labial, dental,
retroflex, palatal, and velar consonant families having its own
column. Almost all vowels are under the left hand, and consonants
under the right hand. Orthography is extremely regular. Some of the
rules of English may not apply, such as word division. There is no
capitalization. Each of the Indic keyboard layouts is very similar to
all of the others.
I would like to get hold of Omar Khayyam Moore's Edison Talking
Typewriter program and rewrite it in a modern programming language. It
ran on an IBM 360 and taught three-year-olds to read and write on a
Selectric terminal with very little human intervention required.
> -Wade
>
> On Fri, Jan 2, 2009 at 6:55 PM, Sascha Silbe
> wrote:
>>
>> On Fri, Jan 02, 2009 at 12:10:09PM -0800, Bryan Berry wrote:
>>
>>> The Typing Turtle will be immensely useful and immensely popular in
>>> Nepal. A typing tutor is one of the most frequently requested programs
>>> by the Nepali kids and teachers alike. Thanks alot to Wade for working
>>> on it.
>>
>> Have you tried TuxType/TuxTyping [1] and (a recent version of) TuxMath?
>> There's no XO bundle for them yet, but if they fit your needs, you might
>> try asking Albert Calahan. He seems to have done the TuxPaint [2] bundle
>> [3,5] (all three programs are from the same project - Tux4Kids [4]).
>>
>>
>> [1] http://tuxtype.sourceforge.net/
>> [2] http://www.tuxpaint.org/
>> [3] http://wiki.laptop.org/go/Tux_Paint
>> [4] http://tux4kids.alioth.debian.org/
>> [5] http://wiki.laptop.org/go/Activities/All
>>
>> CU Sascha
>>
>> --
>> http://sascha.silbe.org/
>> http://www.infra-silbe.de/
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.6 (GNU/Linux)
>>
>> iQEVAwUBSV6pWrpz82VMF3DaAQLL0gf/c8N5HvCAiuM8vNC9TIn5rb5afUtJCb2M
>> pzWMSDDBQYpRQniwi04qgS7exVh0OlYFficKrrZni9dAEVL582zRGzCHVmP7RIda
>> 5PLpA5UOcgQIjGvoyeiBO+yhdx540kmsPU0UWzE7ZQEdAwdJUnlgF5aB/L0pT8H+
>> /0hdMbR1uHrServp6EPikvmkq95lWTf78YR3cLcKjmBF7gvxHNVv5mtFEb5HvbfG
>> SF5lmxNSFWojx7LrHYYA7EArO7vMDvK25sYTofBTZ32cml3egGH6SqPgRW7MiUGj
>> nRmjfYba2Z9FE9AhQsyUkUZUNyqT6sbcrff2zMbJLW5/LIbfQ5gXfw==
>> =cZiZ
>> -----END PGP SIGNATURE-----
>>
>
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
--
Silent Thunder (??/???????????????/????????????? ?) is my name
And Children are my nation.
The Cosmos is my dwelling place, The Truth my destination.
http://wiki.sugarlabs.org/go/User:Mokurai
From tomeu at sugarlabs.org Sat Jan 3 04:26:28 2009
From: tomeu at sugarlabs.org (Tomeu Vizoso)
Date: Sat, 3 Jan 2009 10:26:28 +0100
Subject: [Sugar-devel] web-based activities (was Re: [IAEP] How to Make
Activity Designers Happy , Parts I and II)
In-Reply-To: <1230924646.17108.76.camel@hitman>
References: <242851610901021018r4c84d249r8b348dc126c4bbe9@mail.gmail.com>
<1230924646.17108.76.camel@hitman>
Message-ID: <242851610901030126t1894ef2am6bcb0232be625d4@mail.gmail.com>
On Fri, Jan 2, 2009 at 20:30, Bryan Berry wrote:
> On Fri, 2009-01-02 at 19:18 +0100, Tomeu Vizoso wrote:
>> Hi,
>>
>> without needing to get into what is better for our deployments, I do
>> see value in making easier to make Sugar activities using technologies
>> such as HTML, CSS, etc
>> Bryan, can we get into a more detailed view on what it would take
>> ideally to create a new activity using such activities? Which would be
>> the steps that an experienced web designer would need to take in order
>> to create a Sugar activity?
>
> Presently, we do the following to run flash activities on the XO
>
> 1) download the Firefox3.xo bundle
> 2) change the activity.info file
> 3) change some of the file and directory names to reference
> EPaathActivity instead of FirefoxActivity
> 4) copy the swf (flash) files to ./activity/Activity/Activities (I know
> it's ugly
> 5) change the firefoxactivity.py
> ff = [ './firefox' ]
> to
> ff = [ './firefox', './activity/Activity/Activities/OurSWF.htm']
Doesn't sound too complicated. How is it working right now? Which are
the biggest issues? How do you envision this should be done instead?
>> I'm sure that someone with basic knowledge of python could create some
>> tools that make it much more easier than it is today. Also have some
>> ideas about how those activities could interact with the journal and
>> other Sugar features.
>>
>> Thanks,
>>
>> Tomeu
>
> Again, this requires people to learn python, a whole new language that
> they don't necessarily use at work. We need to enable developers to be
> very productive in just 2-3 hours per week. For them to be productive
> they need to be using tools they are already familiar w/.
>
> Python is a tool popular among sysadmins and hackers. It is great tool.
> But folks who develop web UIs use css, html, javascript, and flash. I
> highly doubt that will change in the near or distant future. These are
> people we need to recruit as activity designers.
I guess I was unclear in my proposal. What I was talking about is
creating a set of tools that the web developers would use. A python
coder would write and maintain them and the web developers would use
them to deploy their work.
Regards,
Tomeu
>> On Fri, Jan 2, 2009 at 02:50, Bryan Berry wrote:
>> > This is a draft of a multi-part article I plan to post to OLPC News.
>> >
>> > It is very long but I would very much appreciate your opinions and
>> > feedback. Your input will make it a better article once published.
>> >
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >
>> > This OLPC project seems to be going pretty well as of late December
>> > 2008. G1G1 v2 is well underway, there are a number of successful pilots
>> > going on, and a number of larger-scale pilots will come online this
>> > spring and coming summer.
>> >
>> > Still, there is a big gaping whole in the middle of our little education
>> > project. There just aren't enough activities. Mind you, we have some
>> > seriously awesome activities such as Etoys, Scratch, TamTam, and others.
>> > We have tremendous depth but very limited breadth.
>> >
>> > By breadth, I mean interactive activities for language, history,
>> > geology, health, etc. In order to expand the range of activities, we
>> > need to recruit a lot more activity developers and make it dead-simple
>> > for them to contribute.
>> >
>> > But Which Developers?
>> >
>> > Let's think about who we want to recruit. We're talking about breadth
>> > here so we need experts on Nepali grammar, Pashto vocabulary, Philippine
>> > history, and Andean geography. The good news is that there are
>> > technically-oriented people out there that know these things and want to
>> > help.
>> >
>> > We already have a hardcore team of dedicated hackers. We need them for
>> > the work that hackers excel at: building infrastructure, testing the
>> > limits of new systems. But now we need a different class of developer,
>> > those that are focused on the presentation, game play and not system
>> > internals.
>> >
>> > Based on these characteristics, let's call these people
>> > designers. The good news is that there are lots of
>> > designers-particularly in developing countries-that want to contribute
>> > to OLPC. The bad news is that they don't know python. or GTK+. They may
>> > not even be familiar with linux. They do know HTML, CSS, Javascript, and
>> > Adobe Flash. Allow me to explain.
>> >
>> > Due to rise of the Internet and related boom in outsourcing, the vast,
>> > vast majority of programmers in developing countries are web developers
>> > (according to my own grossly unscientific survey). The rise of the
>> > Internet has also led a lot of talented graphic designers in developing
>> > and developed countries to learn web technologies. I even
>> > wager that CSS/HTML/Javascript will become the de facto GUI technologies
>> > in a few years time. > > href="http://en.wikipedia.org/wiki/Pygtk">PyGTK won't take over the
>> > world nor will VB.net.
>> >
>> > The popular term for this triumvirate of technologies is > > href="http://en.wikipedia.org/wiki/AJAX">AJAX, with the difference
>> > that AJAX applications typically require communication with a remote
>> > server. I propose using web technologies for completely offline
>> > activities. Adobe's Flash is basically a variant of AJAX that uses
>> > dialects of Javascript (> > href="http://en.wikipedia.org/wiki/Actionscript">Actionscript) and
>> > XML (MXML).
>> >
>> > Very few programmers in the developed world get paid to write desktop
>> > linux apps. Still, open-source developers find learn and build pygtk,
>> > mono, and KDE apps in their free-time. Developers in the developing
>> > world are extremely enthusiastic about FOSS but not nearly as prolific
>> > in creating open-source software due to a phenomenon I
>> > call the "FOSS-Nepal Paradox."
>> >
>> > The > > href="http://wiki.fossnepal.org/index.php?title=The_FOSS_Nepal_Community">FOSS Nepal community has won the award for best celebration of Software Freedom day for two years in a running. Despite all this enthusiasm the FOSS Nepal community is not very prolific in producing open-source code. The reason for this is that Nepal is not a wealthy country and that Open-Source is expensive to produce.
>> >
>> > Open-Source is Expensive
>> >
>> > Open-source software voraciously consumes a resource even more valuable
>> > than hard cash, programmer time. Linus Torvalds could afford to spend
>> > some of the most productive years of his life working without immediate
>> > financial benefit. He could slack off in his classes without fear of
>> > unemployment upon graduation. I doubt his parents were counting on him
>> > to support them financially once he got a job.
>> >
>> > Most talented Nepali programmers I know do not have those luxuries. They
>> > are under a lot of pressure to support their parents and extended
>> > families, financially and otherwise. So Nepalis, Bangladeshis, Peruanos,
>> > etc. certainly have the passion and ability to contribute to open-source
>> > but their free time is significantly more limited.
>> >
>> > This doesn't mean that we should rely on developers from rich countries.
>> > We simply need to radically lower the amount of time required to create
>> > learning activities. I believe that many, many developers in the
>> > developing world can contribute 3-5 hours per week. To make those few
>> > hours productive we need to rework the default activity framework.
>> >
>> > >From what I can tell, the primary design goals of the default PyGTK
>> > activity
>> > framework are as follows:
>> >
>> > - Give the programmer maximum flexibility
- Fully exploit
>> > the XO's hardware features
- Mesh nicely with Sugar
>> >
>> > These three goals are laudable and their hacker roots are obvious. The
>> > problem is that these goals maximize the technology's potential rather
>> > than programmer productivity. We need reach beyond the vi/emacs crowd
>> > (Note: I wrote this article using emacs) to thos folks that the masters
>> > of Photoshop, Adobe Illustrator, Eclipse, and GIMP.
>> >
>> > I propose a new set of design goals:
>> >
>> >
>> > - Allow activity designers to quickly build activities utilizing
>> > widely-used tools.
>> > - Quickly reward effort with working behavior
>> > - Mesh nicely with the Sugar UI
>> >
>> >
>> > It's OK to be Opinionated
>> >
>> > We need an opinionated activity framework that makes infrastructure
>> > choices for the designer so that she can focus presentation and
>> > gameplay. Some may recognize this as the principle of > > href="http://en.wikipedia.org/wiki/Convention_over_Configuration">Convention Over Configuration, a principle that two of the most popular web frameworks, Django and RubyOnRails, adhere to. Now a lot of geeks don't like Convention over Configuration--perl hackers especially--but they sure do allow you to create nice applications very quickly.
>> >
>> > Establishing an "opinionated" activity framework will in no way limit
>> > the freedom of those hackers who want to go their own way. They can
>> > always build their own activities from whatever tools they choose. The
>> > whole point of a framework is to help people get started quickly but it
>> > doesn't constrain anyone.
>> >
>> > This concludes part I. Here are some tantalizing morsels from Part II
>> > of "How to Make Activity Designers Happy,"
>> >
>> >
>> > - Where it's at: HTML, CSS, Javascript, and *gasp* Flash
>> > - Nepal's Content Development Experience
>> > - Aren't Kids going to create all learning activities so we don't
>> > have to?
>> >
>> >
>> >
>> > Bryan Berry is the Technology Director of > > href="http://www.olenepal.org">OLE Nepal and deadbeat co-editor of
>> > OLPCNews.com. Christopher Marin contributed his knowledge about all
>> > things web to this article
>> >
>> >
>> >
>> > In part 1, I talked about the paradoxical
>> > nature of open-source communities in developing countries, flaws in
>> > the current default activity development framework, and the urgent
>> > need for a new framework that makes activity designers happy.
>> >
>> > By happy, I mean that the framework rewards their efforts almost
>> > immediately (roughly 15 minutes of effort) and it lets them focus on
>> > presentation and gameplay rather than infrastructure. Last time I
>> > offered some vague ideas how this framework might function. This time
>> > I will provide more details how this framework could work and why.
>> >
>> > Let's Ride The Internet Wave
>> >
>> > The Internet is the 300-pound gorilla in the software-engineering room
>> > it will eat virtually everything, including your favorite desktop GUI
>> > framework. All of the IDE's bend over backwards to support coding of
>> > webapps, whether it is emacs, eclipse, or even vim. The software
>> > industry is making huge investments into web technologies that support
>> > the triumvirate of HTML/CSS/Javascript, witness Google's investment in
>> > V8 javascript compiler and
>> > Apple's investment in > > href="http://en.wikipedia.org/wiki/WebKit">Webkit. I speculate
>> > that there are many, many more developers working on GUI toolkits for
>> > the web browser- such as JQuery, Prototype, Script.aculo.us-than for
>> > GNOME or KDE desktop frameworks.
>> >
>> > The web will keep innovating at a breakneck pace. We need to ride that
>> > wave of innovation.
>> >
>> > In the early days of OLPC, we all had a lot of grandiose and
>> > impractical ideas. The educational systems of developing countries
>> > would change overnight into constructionist hotbeds. Kids would build
>> > their own activities, eliminating the need for large investments in
>> > content development. A million PyGTK apps with built-in collaboration
>> > and "View-Source" key would spontaneously bloom . . . Well, we're
>> > older and wiser now. School systems anywhere are not blank slates that
>> > we can redraw from scratch using cheap laptops and Etoys. Similarly,
>> > we cannot expect thousands of developers to flock to a framework
>> > (PyGTK) that is not commercially popular.
>> >
>> > Developing Country Developer Economics
>> >
>> > As I wrote in Part I, the economics of open-source in developing
>> > countries is quite different than that in the developed
>> > world. Developers there have ample enthusiasm for open-source but much
>> > less time to contribute.
>> >
>> > We need to lower the barrier of entry significantly in order to use
>> > their talents. In fact, we need to entice non-programmers such as
>> > graphic designers. In my limited experience, graphic designers are
>> > much better at designing learning activities than programmers. They
>> > better appreciate aesthetics and visual story-telling.
>> >
>> > Web designers layout their work using CSS and (X)HTML. They implement
>> > user interaction and animations using Javascript. They design their
>> > work using Photoshop, GIMP, Adobe Illustrator, and sometimes
>> > Eclipse. They know the features and dark areas of the Firefox web
>> > browser. Sugar infrastructure developers, these people are your
>> > customers. We need KARMA to enable them to quickly buidl activities
>> > for the XO without having to learn a whole new skillset. From a
>> > programmatic point of view, Browse needs to behave as much as possible
>> > like Firefox. Any discrepancy will distract activity designers from
>> > the more rewarding parts of activity development.
>> >
>> > Building Good KARMA
>> >
>> > Before we get too far, let's give this new activity framework a name
>> > so I can save us all a lot of excess verbiage. I call it KARMA,
>> > because the word is loosely-related to Nepal, my current residence,
>> > and I like to think creating open-source learning activities gives an
>> > individual good karma. Coincidentally, it is also the first two
>> > syllables of Rabi Karmacharya's last name--an individual put a ton of
>> > hard work and personal sacrifice into the OLPC project in Nepal.
>> >
>> > Well, I haven't actually made up my mind what the core technologies of
>> > KARMA
>> > should be. I need your help to work it out. Before I get into the
>> > technologies, here are my priorities. 1) These tools maximize
>> > programmer productivity and 2) are open-soure. Priority #1 is much
>> > more important than #2. 100% purely open-source activities that don't
>> > exist don't help kids learn. The current pygtk framework is purely
>> > open-source but you have to become a unix programmer to use it. As I
>> > noted in Part I, the vast, vast majority of programmers in the
>> > developing world are web developers and a successful activity
>> > framework will allow them to re-use their existing skills and tools.
>> >
>> > I have settled on HTML and CSS for the presentation but it is tougher
>> > to decide on the scripting toolset and on persistent data
>> > storage. Flash handles animations really well and it is easy to
>> > integrate audio into the animations. Adobe sells some really nice
>> > WYSIWYG tools for editing animation and adding audio. A lot of
>> > developers know flash so there is a large pool of talent we can draw
>> > from. Did I forget to mention that Flash is proprietary?
>> >
>> > The closed-source issue not withstanding, Flash is the tool to
>> > use. Some may be upset that Flash doesn't lend itself to "View Source"
>> > functionality but learning programming is not the sum total of
>> > education. Kids can do all the programming they ever want to w/ the
>> > excellent Etoys and Scratch. Sorry to sound like a broken record, but
>> > Afghani kids won't be able to view the source of Pashto grammar
>> > activities that don't exist, let alone interactively learn the rules
>> > of Pashto grammar.
>> >
>> > Flash Ain't Open-Source
>> >
>> > Flash is not _as_ closed-source as other software applications like
>> > Windows. The Adobe has published the specification for their SWF file
>> > format and the ActionScript 3.0 compiler is open-source. However, the
>> > Adobe's development tools such as Adobe Animator, Illustrator,
>> > Photoshop, etc. are not open-source. Nor is Adobe's flash player
>> > plugin. There is the open-source Gnash player but it does not fully
>> > support Actionscript 3 or Flash version 9. Rob Savoye and his team at
>> > Open Media Now do a great job but they seriously lack resources. Note:
>> > Rob
>> > Savoye, please correct my egregious errors.
>> >
>> > Javascript Isn't Ready
>> >
>> > I put in a good number of research hours into this article. I really,
>> > really wanted to find a pure javascript framework that could compete
>> > with Flash. I couldn't find one that does. There are libraries like
>> > DOJO, JQuery, and Processing.js
>> > http://ejohn.org/blog/processingjs/. Unfortunately, there aren't any
>> > IDE's that provide WYSIWYG animation editing for these tools. Every
>> > try to edit photos from a text editor? It's painful, really
>> > painful. So while real programmers use emacs (or vi, joe, sam, etc.),
>> > designers use WYSIWYG GUI's.
>> >
>> > Sadly, Javascript can't use the Graphics Processing Unit like Flash
>> > can. Ouch, it's a pain in the ass to couple animations with sound
>> > files. Based on my research so far, pure javascript won't be able to
>> > compete with Flash for at least the next several years. Please prove
>> > me wrong. Please post a comment to this article linking to some
>> > Javascript wonderfulness that pulls even with Flash.
>> >
>> >
>> > I will continue with the assumption that KARMA will use flash. I will
>> > happily revise this article ex post facto if someone in cyberspace
>> > points me to a pure javascript solution that makes activity designers
>> > happy.
>> >
>> > Building Momentum for Gnash
>> >
>> > I believe that the best way to increase interest in fully open-source
>> > flash is to make Flash more central in the evolving open-source
>> > education stack rather than minimizing its role. We definitely cannot
>> > wait for Gnash to fully support every feature of the proprietary flash
>> > before we begin using it. Open-Source starts when a single developer
>> > "scratches an itch" as the proverb goes. It follows then that the best
>> > way to bring Gnash up to speed we need to create a nasty, festering
>> > sore that irritates the open-source community into action.
>> >
>> > Moving the Conversation Forward
>> >
>> > Many people will likely hate my promotion of Flash for learning
>> > activities. It's OK if you hate me and Flash. I do hope you recognize
>> > that we need a more developer-centric activity framework that uses web
>> > technologies.
>> >
>> > I have a lot more to write about Nepal's experiences developing
>> > learning activities and my ideas on Convention over Configuration in
>> > sugar activities. I will save those for another day.
>> >
>> >
>> > --
>> > Bryan W. Berry
>> > Technology Director
>> > OLE Nepal, http://www.olenepal.org
>> >
>> > _______________________________________________
>> > IAEP -- It's An Education Project (not a laptop project!)
>> > IAEP at lists.sugarlabs.org
>> > http://lists.sugarlabs.org/listinfo/iaep
>> >
> --
> Bryan W. Berry
> Technology Director
> OLE Nepal, http://www.olenepal.org
>
>
From tomeu at sugarlabs.org Sat Jan 3 04:31:42 2009
From: tomeu at sugarlabs.org (Tomeu Vizoso)
Date: Sat, 3 Jan 2009 10:31:42 +0100
Subject: [Sugar-devel] web-based activities (was Re: [IAEP] How to Make
Activity Designers Happy , Parts I and II)
In-Reply-To: <7087c32a0901021132s7423157av3ad1cfa4267b9326@mail.gmail.com>
References: <242851610901021018r4c84d249r8b348dc126c4bbe9@mail.gmail.com>
<7087c32a0901021132s7423157av3ad1cfa4267b9326@mail.gmail.com>
Message-ID: <242851610901030131t142b604fw52d83cd75dbbbe29@mail.gmail.com>
Sounds very in line with what we have been talking to date, plus you
add some very good ideas like using the integrated web server for
accessing the journal.
Also, some web (server side) developers have asked for some way of
running web applications as Sugar activities. I guess in this scenario
we are limited by the resource requirements of most web apps that
require a specific http server, database server, etc. But I think
there's place anyway to provide some amount of support for server side
web apps.
Thanks,
Tomeu
On Fri, Jan 2, 2009 at 20:32, Wade Brainerd wrote:
> The work we did for WikiBrowse (the WikipediaES and WikipediaEN) activities
> would make a good starting point.
>
> First of all the Browse code should be integrated into Sugar. This has been
> discussed before, and makes sense since you guys are maintaining the Browse
> activity anyway.
>
> The Browse code would be provided as a base
> sugar.activity.webactivity.WebActivity class. Currently, "web-based"
> activities (not content bundles) need to manually find the path to the
> Browse installation (assuming there is one!) and import its modules which
> feels rather hacky.
>
> The sugar.activity.webactivity module should also provide a WebServer
> class. This class is a SimpleHTTPServer derivative which supports iterating
> and finding and returning an unused local port to serve over. The server
> would handle GET/POST requests to a special '/journal/' URL prefix,
> allowing DHTML scripts access to the activity's Journal entry.
>
> Finally, a web-activity launcher script should be created. This script
> launches the Sugar Browse code and supports a variety of command line
> options to control what parts of the Browse UI are enabled, and to set the
> home page. It should be possible to launch a Browse instance with nothing
> but the Activity toolbar for example.
>
> These steps will allow for three (or more!) different variations on
> "web-based" activities:
>
> 1) Static HTML and/or DHTML ala the existing .xol system. A collection of
> .html, css and .js files can be bundled as a .xo file. The included
> activity.info exec line calls web-activity with appropriate command line
> options.
>
> The advantage of this approach over .xol files is that the "web-based
> activity" appears as a first class object in the Sugar UI with an
> independent icon on the Home view. Further, since the
> sugar.activity.webactivity.WebServer is used, DHTML code can read/write from
> the activity's Journal entry.
>
> 2) Static HTML and/or DHTML with custom UI. In WikiBrowse, I subclassed
> WebActivity and added a new Search toolbar, which searches the wiki DB and
> retrieves a page of results. This is the same as variation 1, except
> instead of calling "web-activity", a new Python activity class is derived
> from sugar.activity.webactivity.WebActivity and modifies the UI in some way
> - adding toolbars, etc.
>
> 3) Static HTML and/or DHTML with custom server. In WikiBrowse, a custom
> webserver attaches to a local port and serves wiki pages. It decompresses
> and formats wiki pages before serving them up as XHTML. So in this
> variation, a simple Python WebServer class is derived from
> sugar.activity.webactivity.WebServer and the appropriate page request
> handing methods are added. The base WebServer class additionally handles
> GET/POST request to access the Journal entry for the activity.
>
> Doing this work would allow us to rewrite WikiBrowse in a much cleaner
> fashion, and would allow a whole range of first class Web-based Sugar
> activities.
>
> Cheers,
> Wade
>
> On Fri, Jan 2, 2009 at 1:18 PM, Tomeu Vizoso wrote:
>>
>> Hi,
>>
>> without needing to get into what is better for our deployments, I do
>> see value in making easier to make Sugar activities using technologies
>> such as HTML, CSS, etc
>>
>> Bryan, can we get into a more detailed view on what it would take
>> ideally to create a new activity using such activities? Which would be
>> the steps that an experienced web designer would need to take in order
>> to create a Sugar activity?
>>
>> I'm sure that someone with basic knowledge of python could create some
>> tools that make it much more easier than it is today. Also have some
>> ideas about how those activities could interact with the journal and
>> other Sugar features.
>>
>> Thanks,
>>
>> Tomeu
>>
>> On Fri, Jan 2, 2009 at 02:50, Bryan Berry wrote:
>> > This is a draft of a multi-part article I plan to post to OLPC News.
>> >
>> > It is very long but I would very much appreciate your opinions and
>> > feedback. Your input will make it a better article once published.
>> >
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >
>> > This OLPC project seems to be going pretty well as of late December
>> > 2008. G1G1 v2 is well underway, there are a number of successful pilots
>> > going on, and a number of larger-scale pilots will come online this
>> > spring and coming summer.
>> >
>> > Still, there is a big gaping whole in the middle of our little education
>> > project. There just aren't enough activities. Mind you, we have some
>> > seriously awesome activities such as Etoys, Scratch, TamTam, and others.
>> > We have tremendous depth but very limited breadth.
>> >
>> > By breadth, I mean interactive activities for language, history,
>> > geology, health, etc. In order to expand the range of activities, we
>> > need to recruit a lot more activity developers and make it dead-simple
>> > for them to contribute.
>> >
>> > But Which Developers?
>> >
>> > Let's think about who we want to recruit. We're talking about breadth
>> > here so we need experts on Nepali grammar, Pashto vocabulary, Philippine
>> > history, and Andean geography. The good news is that there are
>> > technically-oriented people out there that know these things and want to
>> > help.
>> >
>> > We already have a hardcore team of dedicated hackers. We need them for
>> > the work that hackers excel at: building infrastructure, testing the
>> > limits of new systems. But now we need a different class of developer,
>> > those that are focused on the presentation, game play and not system
>> > internals.
>> >
>> > Based on these characteristics, let's call these people
>> > designers. The good news is that there are lots of
>> > designers-particularly in developing countries-that want to contribute
>> > to OLPC. The bad news is that they don't know python. or GTK+. They may
>> > not even be familiar with linux. They do know HTML, CSS, Javascript, and
>> > Adobe Flash. Allow me to explain.
>> >
>> > Due to rise of the Internet and related boom in outsourcing, the vast,
>> > vast majority of programmers in developing countries are web developers
>> > (according to my own grossly unscientific survey). The rise of the
>> > Internet has also led a lot of talented graphic designers in developing
>> > and developed countries to learn web technologies. I even
>> > wager that CSS/HTML/Javascript will become the de facto GUI technologies
>> > in a few years time. > > href="http://en.wikipedia.org/wiki/Pygtk">PyGTK won't take over the
>> > world nor will VB.net.
>> >
>> > The popular term for this triumvirate of technologies is > > href="http://en.wikipedia.org/wiki/AJAX">AJAX, with the difference
>> > that AJAX applications typically require communication with a remote
>> > server. I propose using web technologies for completely offline
>> > activities. Adobe's Flash is basically a variant of AJAX that uses
>> > dialects of Javascript (> > href="http://en.wikipedia.org/wiki/Actionscript">Actionscript) and
>> > XML (MXML).
>> >
>> > Very few programmers in the developed world get paid to write desktop
>> > linux apps. Still, open-source developers find learn and build pygtk,
>> > mono, and KDE apps in their free-time. Developers in the developing
>> > world are extremely enthusiastic about FOSS but not nearly as prolific
>> > in creating open-source software due to a phenomenon I
>> > call the "FOSS-Nepal Paradox."
>> >
>> > The > >
>> > href="http://wiki.fossnepal.org/index.php?title=The_FOSS_Nepal_Community">FOSS
>> > Nepal community has > > href="http://softwarefreedomday.org/Competition2008">won the award for
>> > best celebration of Software Freedom day for two years in a running.
>> > Despite all this enthusiasm the FOSS Nepal community is not very prolific
>> > in producing open-source code. The reason for this is that Nepal is not a
>> > wealthy country and that Open-Source is expensive
>> > to produce.
>> >
>> > Open-Source is Expensive
>> >
>> > Open-source software voraciously consumes a resource even more valuable
>> > than hard cash, programmer time. Linus Torvalds could afford to spend
>> > some of the most productive years of his life working without immediate
>> > financial benefit. He could slack off in his classes without fear of
>> > unemployment upon graduation. I doubt his parents were counting on him
>> > to support them financially once he got a job.
>> >
>> > Most talented Nepali programmers I know do not have those luxuries. They
>> > are under a lot of pressure to support their parents and extended
>> > families, financially and otherwise. So Nepalis, Bangladeshis, Peruanos,
>> > etc. certainly have the passion and ability to contribute to open-source
>> > but their free time is significantly more limited.
>> >
>> > This doesn't mean that we should rely on developers from rich countries.
>> > We simply need to radically lower the amount of time required to create
>> > learning activities. I believe that many, many developers in the
>> > developing world can contribute 3-5 hours per week. To make those few
>> > hours productive we need to rework the default activity framework.
>> >
>> > >From what I can tell, the primary design goals of the default PyGTK
>> > activity
>> > framework are as follows:
>> >
>> > - Give the programmer maximum flexibility
- Fully exploit
>> > the XO's hardware features
- Mesh nicely with Sugar
>> >
>> > These three goals are laudable and their hacker roots are obvious. The
>> > problem is that these goals maximize the technology's potential rather
>> > than programmer productivity. We need reach beyond the vi/emacs crowd
>> > (Note: I wrote this article using emacs) to thos folks that the masters
>> > of Photoshop, Adobe Illustrator, Eclipse, and GIMP.
>> >
>> > I propose a new set of design goals:
>> >
>> >
>> > - Allow activity designers to quickly build activities
>> > utilizing
>> > widely-used tools.
>> > - Quickly reward effort with working behavior
>> > - Mesh nicely with the Sugar UI
>> >
>> >
>> > It's OK to be Opinionated
>> >
>> > We need an opinionated activity framework that makes infrastructure
>> > choices for the designer so that she can focus presentation and
>> > gameplay. Some may recognize this as the principle of > >
>> > href="http://en.wikipedia.org/wiki/Convention_over_Configuration">Convention
>> > Over Configuration, a principle that two of the most popular web
>> > frameworks, Django and RubyOnRails, adhere to. Now a lot of geeks don't like
>> > Convention over Configuration--perl hackers especially--but they sure do
>> > allow you to create nice applications very quickly.
>> >
>> > Establishing an "opinionated" activity framework will in no way limit
>> > the freedom of those hackers who want to go their own way. They can
>> > always build their own activities from whatever tools they choose. The
>> > whole point of a framework is to help people get started quickly but it
>> > doesn't constrain anyone.
>> >
>> > This concludes part I. Here are some tantalizing morsels from Part II
>> > of "How to Make Activity Designers Happy,"
>> >
>> >
>> > - Where it's at: HTML, CSS, Javascript, and *gasp* Flash
>> > - Nepal's Content Development Experience
>> > - Aren't Kids going to create all learning activities so we
>> > don't
>> > have to?
>> >
>> >
>> >
>> > Bryan Berry is the Technology Director of > > href="http://www.olenepal.org">OLE Nepal and deadbeat co-editor of
>> > OLPCNews.com. Christopher Marin contributed his knowledge about all
>> > things web to this article
>> >
>> >
>> >
>> > In part 1, I talked about the paradoxical
>> > nature of open-source communities in developing countries, flaws in
>> > the current default activity development framework, and the urgent
>> > need for a new framework that makes activity designers happy.
>> >
>> > By happy, I mean that the framework rewards their efforts almost
>> > immediately (roughly 15 minutes of effort) and it lets them focus on
>> > presentation and gameplay rather than infrastructure. Last time I
>> > offered some vague ideas how this framework might function. This time
>> > I will provide more details how this framework could work and why.
>> >
>> > Let's Ride The Internet Wave
>> >
>> > The Internet is the 300-pound gorilla in the software-engineering room
>> > it will eat virtually everything, including your favorite desktop GUI
>> > framework. All of the IDE's bend over backwards to support coding of
>> > webapps, whether it is emacs, eclipse, or even vim. The software
>> > industry is making huge investments into web technologies that support
>> > the triumvirate of HTML/CSS/Javascript, witness Google's investment in
>> > V8 javascript compiler and
>> > Apple's investment in > > href="http://en.wikipedia.org/wiki/WebKit">Webkit. I speculate
>> > that there are many, many more developers working on GUI toolkits for
>> > the web browser- such as JQuery, Prototype, Script.aculo.us-than for
>> > GNOME or KDE desktop frameworks.
>> >
>> > The web will keep innovating at a breakneck pace. We need to ride that
>> > wave of innovation.
>> >
>> > In the early days of OLPC, we all had a lot of grandiose and
>> > impractical ideas. The educational systems of developing countries
>> > would change overnight into constructionist hotbeds. Kids would build
>> > their own activities, eliminating the need for large investments in
>> > content development. A million PyGTK apps with built-in collaboration
>> > and "View-Source" key would spontaneously bloom . . . Well, we're
>> > older and wiser now. School systems anywhere are not blank slates that
>> > we can redraw from scratch using cheap laptops and Etoys. Similarly,
>> > we cannot expect thousands of developers to flock to a framework
>> > (PyGTK) that is not commercially popular.
>> >
>> > Developing Country Developer Economics
>> >
>> > As I wrote in Part I, the economics of open-source in developing
>> > countries is quite different than that in the developed
>> > world. Developers there have ample enthusiasm for open-source but much
>> > less time to contribute.
>> >
>> > We need to lower the barrier of entry significantly in order to use
>> > their talents. In fact, we need to entice non-programmers such as
>> > graphic designers. In my limited experience, graphic designers are
>> > much better at designing learning activities than programmers. They
>> > better appreciate aesthetics and visual story-telling.
>> >
>> > Web designers layout their work using CSS and (X)HTML. They implement
>> > user interaction and animations using Javascript. They design their
>> > work using Photoshop, GIMP, Adobe Illustrator, and sometimes
>> > Eclipse. They know the features and dark areas of the Firefox web
>> > browser. Sugar infrastructure developers, these people are your
>> > customers. We need KARMA to enable them to quickly buidl activities
>> > for the XO without having to learn a whole new skillset. From a
>> > programmatic point of view, Browse needs to behave as much as possible
>> > like Firefox. Any discrepancy will distract activity designers from
>> > the more rewarding parts of activity development.
>> >
>> > Building Good KARMA
>> >
>> > Before we get too far, let's give this new activity framework a name
>> > so I can save us all a lot of excess verbiage. I call it KARMA,
>> > because the word is loosely-related to Nepal, my current residence,
>> > and I like to think creating open-source learning activities gives an
>> > individual good karma. Coincidentally, it is also the first two
>> > syllables of Rabi Karmacharya's last name--an individual put a ton of
>> > hard work and personal sacrifice into the OLPC project in Nepal.
>> >
>> > Well, I haven't actually made up my mind what the core technologies of
>> > KARMA
>> > should be. I need your help to work it out. Before I get into the
>> > technologies, here are my priorities. 1) These tools maximize
>> > programmer productivity and 2) are open-soure. Priority #1 is much
>> > more important than #2. 100% purely open-source activities that don't
>> > exist don't help kids learn. The current pygtk framework is purely
>> > open-source but you have to become a unix programmer to use it. As I
>> > noted in Part I, the vast, vast majority of programmers in the
>> > developing world are web developers and a successful activity
>> > framework will allow them to re-use their existing skills and tools.
>> >
>> > I have settled on HTML and CSS for the presentation but it is tougher
>> > to decide on the scripting toolset and on persistent data
>> > storage. Flash handles animations really well and it is easy to
>> > integrate audio into the animations. Adobe sells some really nice
>> > WYSIWYG tools for editing animation and adding audio. A lot of
>> > developers know flash so there is a large pool of talent we can draw
>> > from. Did I forget to mention that Flash is proprietary?
>> >
>> > The closed-source issue not withstanding, Flash is the tool to
>> > use. Some may be upset that Flash doesn't lend itself to "View Source"
>> > functionality but learning programming is not the sum total of
>> > education. Kids can do all the programming they ever want to w/ the
>> > excellent Etoys and Scratch. Sorry to sound like a broken record, but
>> > Afghani kids won't be able to view the source of Pashto grammar
>> > activities that don't exist, let alone interactively learn the rules
>> > of Pashto grammar.
>> >
>> > Flash Ain't Open-Source
>> >
>> > Flash is not _as_ closed-source as other software applications like
>> > Windows. The Adobe has published the specification for their SWF file
>> > format and the ActionScript 3.0 compiler is open-source. However, the
>> > Adobe's development tools such as Adobe Animator, Illustrator,
>> > Photoshop, etc. are not open-source. Nor is Adobe's flash player
>> > plugin. There is the open-source Gnash player but it does not fully
>> > support Actionscript 3 or Flash version 9. Rob Savoye and his team at
>> > Open Media Now do a great job but they seriously lack resources. Note:
>> > Rob
>> > Savoye, please correct my egregious errors.
>> >
>> > Javascript Isn't Ready
>> >
>> > I put in a good number of research hours into this article. I really,
>> > really wanted to find a pure javascript framework that could compete
>> > with Flash. I couldn't find one that does. There are libraries like
>> > DOJO, JQuery, and Processing.js
>> > http://ejohn.org/blog/processingjs/. Unfortunately, there aren't any
>> > IDE's that provide WYSIWYG animation editing for these tools. Every
>> > try to edit photos from a text editor? It's painful, really
>> > painful. So while real programmers use emacs (or vi, joe, sam, etc.),
>> > designers use WYSIWYG GUI's.
>> >
>> > Sadly, Javascript can't use the Graphics Processing Unit like Flash
>> > can. Ouch, it's a pain in the ass to couple animations with sound
>> > files. Based on my research so far, pure javascript won't be able to
>> > compete with Flash for at least the next several years. Please prove
>> > me wrong. Please post a comment to this article linking to some
>> > Javascript wonderfulness that pulls even with Flash.
>> >
>> >
>> > I will continue with the assumption that KARMA will use flash. I will
>> > happily revise this article ex post facto if someone in cyberspace
>> > points me to a pure javascript solution that makes activity designers
>> > happy.
>> >
>> > Building Momentum for Gnash
>> >
>> > I believe that the best way to increase interest in fully open-source
>> > flash is to make Flash more central in the evolving open-source
>> > education stack rather than minimizing its role. We definitely cannot
>> > wait for Gnash to fully support every feature of the proprietary flash
>> > before we begin using it. Open-Source starts when a single developer
>> > "scratches an itch" as the proverb goes. It follows then that the best
>> > way to bring Gnash up to speed we need to create a nasty, festering
>> > sore that irritates the open-source community into action.
>> >
>> > Moving the Conversation Forward
>> >
>> > Many people will likely hate my promotion of Flash for learning
>> > activities. It's OK if you hate me and Flash. I do hope you recognize
>> > that we need a more developer-centric activity framework that uses web
>> > technologies.
>> >
>> > I have a lot more to write about Nepal's experiences developing
>> > learning activities and my ideas on Convention over Configuration in
>> > sugar activities. I will save those for another day.
>> >
>> >
>> > --
>> > Bryan W. Berry
>> > Technology Director
>> > OLE Nepal, http://www.olenepal.org
>> >
>> > _______________________________________________
>> > IAEP -- It's An Education Project (not a laptop project!)
>> > IAEP at lists.sugarlabs.org
>> > http://lists.sugarlabs.org/listinfo/iaep
>> >
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
From tomeu at sugarlabs.org Sat Jan 3 04:48:05 2009
From: tomeu at sugarlabs.org (Tomeu Vizoso)
Date: Sat, 3 Jan 2009 10:48:05 +0100
Subject: [Sugar-devel] TA with sensors
In-Reply-To:
References:
Message-ID: <242851610901030148m2f013e2fw2483aa5c52e0258d@mail.gmail.com>
Also, see the link below for a way to detect when the activity window
is visible or not:
http://git.sugarlabs.org/projects/sugar/repos/mainline/blobs/master/src/jarabe/journal/journalactivity.py#line298
It's used by the journal in order to decide whether it needs to auto
refresh its view or not.
Regards,
Tomeu
On Sat, Jan 3, 2009 at 05:19, Arjun Sarwal wrote:
> On Sat, Jan 3, 2009 at 1:18 AM, Walter Bender wrote:
>> Thanks for this background.
>>
>> I think that the try/exception mechanism is adequate for our needs. It
>> will be otherwise trivial for me to add the sensor features to the
>> main branch of TA... I'll add it to the next release.
>>
>> I wonder if there is a mechanism we can call upon (Sugar should
>> perhaps provide this) that will tell us that we are being sent to the
>> background so that we can only reinitialize when we go away and come
>> back? It seems that for every call to the sensor, it is a large
>> overhead to incur...
>>
>
> There are signals in Sugar that are fired when an Activity becomes the
> background Activity or foreground Activity (I've used these in Measure
> code). It seems like a good idea to explore to keep the capture device
> ON while TurtleArt is the active Activity and leave the audio device
> when Activity is in background and then re-initialize it when
> TurtleArt becomes the active Activity.
>
>> -walter
>>
>> On Fri, Jan 2, 2009 at 2:25 PM, Arjun Sarwal wrote:
>>> Hello Walter,
>>>
>>> Thank you for the new year wishes. Best wishes to you too for the new
>>> year! (hope you received my card too)
>>>
>>> A few points regarding adding sensor support
>>>
>>> * Calls to Alsamixer to set the DC mode on/off will result in an
>>> exception on one's normal laptop. This is because the DC mode controls
>>> don't exist in the Alsamixer of a normal laptop (even sugar emulation
>>> makes calls to the laptop's default alsamixer)
>>>
>>> * I had put in initializations before each call to the sensor because
>>> - user may switch to another Activity in between a session of Turtle
>>> Art -- the other Activity may use the laptop's sound device. The
>>> other Activity may alter the sound device settings.
>>> - unless a call for sensor input is being made, I didn't want to keep
>>> the capture device active.
>>> The capture device can be thought to be in a state of 'recording
>>> sound' when one is getting sensor input data, hence only one
>>> Activity/program can have access to it at one time.
>>> However, any suggestions you may have on the above implementation
>>> would be very welcome.
>>>
>>>
>>> * If it helps, I am summarizing approximately the changes I made in
>>> TurtleArt to add sensor support and some relevant lines to look at
>>> within the TA with Sensors code that I had made for the earlier (non
>>> SVG version of TAwithSensors):
>>> Referring to the version of the online git tree ('Initial import')
>>> (http://dev.laptop.org/git?p=users/arjs/TurtleArtwithSensors;a=tree;h=3f22f9f86d60f6160268c52009273eba82dba465;hb=3f22f9f86d60f6160268c52009273eba82dba465)
>>>
>>> - audiograb.py as an additional file was included completely
>>> - talogo.py :
>>> (note that lines 8 and 9 in this version of git tree would need to be
>>> changed to
>>> from numpy.oldnumeric import *
>>> from numpy.fft import * )
>>> lines 8,9,11,12 were added
>>> lines 366 onwards till the end have been added
>>> -tasetup.py: lines 47 to 51 to account for the additional sensor
>>> blocks in the UI
>>>
>>> As you can see from the code of talogo.py , the approach involves a
>>> lot of painful starting the whole gstreamer pipeline, getting one
>>> sample then stopping the pipeline. An overkill for getting just one
>>> sample, but there is no way unless python alsa audio is included in
>>> the build system. The approach with python alsa audio is work in
>>> progress here (
>>> http://dev.laptop.org/git?p=users/arjs/TurtleArtwithSensors;a=tree )
>>>
>>> I want to work on incorporating sensor support into the SVG version of
>>> TA that you have made, but my current day job isn't leaving me any
>>> time these days to do anything else. I will get to it as soon as I get
>>> the opportunity, but if in the meanwhile you get a chance to do it -
>>> it'd be great.
>>>
>>> Please let me know if I can help further.
>>>
>>> Kind Regards
>>> Arjun
>>>
>>> On Fri, Jan 2, 2009 at 3:18 AM, Walter Bender wrote:
>>>>
>>>> I've begun folding TA with sensors into TA. I use an exception to
>>>> catch the calls to set DC Mode in Alsamixer, so it seems to run fine
>>>> on my normal laptop using the mic input. But when I look at the logs,
>>>> it seems that there is a lot of initialization that happens with every
>>>> call to the sensor. Is that all necessary? Can we just check for
>>>> changes after the first time?
>>>>
>>>> -walter
>>>>
>>>>
>>>>
>>>> # test to see if DC Mode is enabled
>>>> try:
>>>> self.dcmode = Mixer('DC Mode Enable')
>>>> self.bias = Mixer('V_REFOUT Enable')
>>>> self.has_dcmode = True
>>>> except:
>>>> print "DC Mode unavailable"
>>>> self.has_dcmode = False
>>>>
>>>>
>>>>
>>>> Walter Bender
>>>> Sugar Labs
>>>> http://www.sugarlabs.org
>>>
>>>
>>>
>>> --
>>> Arjun Sarwal
>>>
>>
>>
>>
>> --
>> Walter Bender
>> Sugar Labs
>> http://www.sugarlabs.org
>>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
From tomeu at sugarlabs.org Sat Jan 3 06:22:55 2009
From: tomeu at sugarlabs.org (Tomeu Vizoso)
Date: Sat, 3 Jan 2009 12:22:55 +0100
Subject: [Sugar-devel] Sugar Architecture Documentation
In-Reply-To:
References: <50313.80950.qm@web65506.mail.ac4.yahoo.com>
Message-ID: <242851610901030322q5c9efb57id5650b123aa6f6a9@mail.gmail.com>
On Mon, Dec 22, 2008 at 20:35, Morgan Collett wrote:
> On Mon, Dec 22, 2008 at 19:58, David Farning wrote:
>> On Tue, Nov 4, 2008 at 3:10 AM, wrote:
>>> Hi David,
>>>
>>> As I am in between jobs, I do some volunteer work with the local OLPC
>>> office, helping them in technical and regulatory matters. However, my
>>> primary interest is software and have also been working with Walter on a
>>> proposal to globalize Sugar development.
>>>
>>> I stay in touch with Sugar activities through the Wiki and have been trying
>>> to get a handle on the articecture. Basically, how it complements/meshes
>>> with LINUX. Came across a good article on Bitfrost and one written by you
>>> on APIDOX. From my experience I know that this learning process is
>>> iterative and a lot comes with practical involvement but I would still
>>> appreciate if you can point me to some documents that give me an overview of
>>> the architecture.
>
> Our architecture overview is
> http://sugarlabs.org/go/DevelopmentTeam/Architecture - quite sparse
> but feel free to ask specific questions on this list and we can
> provide the details.
Just wanted to note that one of the reasons for that page to be so
scarce on details is that we are following pretty closely the
architecture of other X11 desktop environments like GNOME, KDE, etc,
so though we could extend quite deeply on several aspects, most of it
wouldn't be Sugar specific.
And yeah, please ask any questions you have and we'll fill those
wholes in the wiki.
Thanks,
Tomeu
>>> To give you and idea of my absorption capacity (or lack thereof), l must add
>>> that I wrote code for DMERT (production system in 5ESS switch) based on UNIX
>>> SVR2 and was responsible for the R&D UNIX Kernel Development (retrofitting
>>> the standard UNIX scheduler to the R&D version). But for the past 17 years
>>> I have been out of internals and spent most of the time on user level
>>> services (Windows Netowrking, MS Exchange, MS SMS), Salses Support, Project
>>> Design, Government Policy, etc. I am OK with OOP concepts though.
>>>
>>> Regards,
>>> Tariq Badsha
>>>
>> Tariq,
>>
>> I have cced your request to the sugar development list. One of the
>> developers will be able to help you out more then I can.
>>
>> thanks
>> david
>
> Regards
> Morgan
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
From tomeu at sugarlabs.org Sat Jan 3 06:37:15 2009
From: tomeu at sugarlabs.org (Tomeu Vizoso)
Date: Sat, 3 Jan 2009 12:37:15 +0100
Subject: [Sugar-devel] [RELEASE] Calculate 26
In-Reply-To:
References:
Message-ID: <242851610901030337x125eddbapfe2fb8bd0d6a655@mail.gmail.com>
Hi Reinier, nice to hear from you.
On Wed, Dec 24, 2008 at 01:09, Reinier Heeres wrote:
> Hi all,
>
> I just released a new version of Calculate. I know I missed the feature
> freeze by about a week, but I was still quite busy finishing the code
> refactoring.
We actually moved the dates some time ago, the feature freeze is
actually Jan 16:
http://sugarlabs.org/go/DevelopmentTeam/Release/Roadmap
> Available at:
> XO: http://dev.laptop.org/~rwh/calculate/Calculate-26.xo
> tarball:
> http://dev.laptop.org/pub/sugar/sources/Calculate/Calculate-26.tar.bz2
>
> Many things are improved, from NEWS with a bit more comment:
>
> * Move to new equation parser based on python ast
> Calculate now uses the internal python parser to create an Abstract Syntax
> Tree (ast). The tree for an equation is evaluated by Calculate itself, so
> that operators (mostly divide) can give different results from standard
> python (e.g. return Rational numbers). The way functions, help and constants
> are included is also much improved and easier to extend by modifying the
> files functions.py and constants.py. Speed increase is about a factor 10,
> especially noticeable when plotting. (It's also less code and easier to
> maintain!)
>
> * Refactor sharing
> This is a major improvement and simplifcation. I recommend other activity
> authors and sugar developers to have a look at shareable_activity.py. This
> provides a class to easily create activities that can be shared (by
> inheriting from ShareableActivity). It automatically sets-up a DBus tube and
> a service to communicate between a shared instance. Communication is exposed
> by the function send_message('message_name', param1=1, param2=2, ...) that
> can be processed on the other end through a registered callback or by
> overloading the function message_received(). I think this could really be
> sufficient for most Activities.
>
> I tested on 767 but it is also compatible with newer api. This could also be
> a good reason to use shareable_activity.py: keep sugar-sharing-api-version
> voodoo out of the main activity code and keep it more readable. It could
> result in less overall duplicate code (a good thing!).
>
> * Refactored equation drawing code
> Adding an equation was slow due to the whole list being regenerated. This is
> not the case anymore.
>
> * Add languages: bi, cs, en_US, fi, he, hu, sk, sv, sw, wa
>
> This is a development release and I expect a few bugs; if you find any,
> please report them. Testing is appreciated!
>
> I'm aware that I probably should move this code over to sugarlabs; however,
> I think I don't have access there yet. Marco, Tomeu, Simon, Bernie, any
> pointers?
You don't need to ask for access in order to host the git tree, just
open an account in git.sugarlabs.org and push to your new tree.
http://sugarlabs.org/go/DevelopmentTeam/Git
About uploading tarballs, I think you need to ask for an account to bernie.
Regards,
Tomeu
> Regards,
> --
> Reinier Heeres
> Waalstraat 17
> 2515 XK Den Haag
> The Netherlands
>
> Tel: +31 6 10852639
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
From tony_anderson at usa.net Sat Jan 3 07:31:50 2009
From: tony_anderson at usa.net (Tony Anderson)
Date: Sat, 03 Jan 2009 07:31:50 -0500
Subject: [Sugar-devel] Education on the XO
Message-ID: <495F5AB6.2060806@usa.net>
Bryan has started a very interesting discussion about what is needed for
the XO to support education. I would like to add my two cents worth.
We are learning (gaining new experience) every day that we are alive.
The traditional difference in education is that it is organized
learning. Teaching a topic means to provide an organized tour of an area
of knowledge covering what every student should know or be aware of.
The XO's primary tool for education, as opposed to learning experiences,
is Moodle. The problem is that Moodle for the XO is a tool which is
ready and waiting to be used (all dressed up and no where to go).
My vision is that there is a repository (website) which contains free
(CC or similar) courses covering the core curriculum for K-8. The
website needs to be supported by a community of developers (course
creators) and moderators (folks who volunteer to assist teachers and
students who are participating). This repository should also contain
'elective' courses following the model of Oregon's Saturday Academy
(http://www.saturdayacademy.org/).
A Moodle course is divided into sections (topics, weeks, ...). Each
section has one or more 'activities' (a word which is very heavily
overloaded). Essentially an 'activity' here is something the course
creator asks the students to do or experience (e.g. read an exposition
on the topic in a wiki page, listen to some music, create an e-toy
project, answer some questions, ...). Moodle provides the teacher with a
wealth of information on the progress of each student.
This organization suggests that course developers could start a new
course or add sections to an existing course or add activities to an
existing section. It also suggests that teachers in a local community
could 'cut and paste' a course from these elements, adding or modifying
as needed.
The moderators would be new element. In the case of the Saturday Academy
courses, they could be the 'teacher' working with a 'cohort' of enrolled
students, who could be anywhere in the world. In the case of 'core'
courses, they could provide help to the classroom teacher as well as
helping to mentor students at the invitation of the teacher. For
example, a class in Rwanda studying English could ask a moderator who is
a native English speaker to meet with them at a specified time to tell
them a story or host a chat. The teacher could ask the moderator to
review student submissions (recorded audio or written material) for
appropriate pronunciation or use of the language.
The primary problem with Moodle at the moment is that there are is not a
body of grade school courses available to illustrate how to build them
or to provoke the community to 'make it better'. Unfortunately, at the
moment, many people in the community do not consider the schoolserver to
be essential, existing Moodle courses are primarily aimed at the
university or pre-university level, and most of these are behind
proprietary walls.
Tony
From solutiongrove at gmail.com Sat Jan 3 09:02:24 2009
From: solutiongrove at gmail.com (Caroline Meeks)
Date: Sat, 3 Jan 2009 09:02:24 -0500
Subject: [Sugar-devel] Education on the XO
In-Reply-To: <495F5AB6.2060806@usa.net>
References: <495F5AB6.2060806@usa.net>
Message-ID:
Hi Tony,
I agree that content and activities that are delivered via Moodle should be
an important part of this project. Have you done any research into what
content is currently available? Who do you think are our best partners for
creating and maintaining a collection of K-8 resources that can be accessed
via Moodle? Curriki? Merlot? Which countries are ahead in this?
Thanks,
Caroline
On Sat, Jan 3, 2009 at 7:31 AM, Tony Anderson wrote:
> Bryan has started a very interesting discussion about what is needed for
> the XO to support education. I would like to add my two cents worth.
>
> We are learning (gaining new experience) every day that we are alive.
> The traditional difference in education is that it is organized
> learning. Teaching a topic means to provide an organized tour of an area
> of knowledge covering what every student should know or be aware of.
>
> The XO's primary tool for education, as opposed to learning experiences,
> is Moodle. The problem is that Moodle for the XO is a tool which is
> ready and waiting to be used (all dressed up and no where to go).
>
> My vision is that there is a repository (website) which contains free
> (CC or similar) courses covering the core curriculum for K-8. The
> website needs to be supported by a community of developers (course
> creators) and moderators (folks who volunteer to assist teachers and
> students who are participating). This repository should also contain
> 'elective' courses following the model of Oregon's Saturday Academy
> (http://www.saturdayacademy.org/).
>
> A Moodle course is divided into sections (topics, weeks, ...). Each
> section has one or more 'activities' (a word which is very heavily
> overloaded). Essentially an 'activity' here is something the course
> creator asks the students to do or experience (e.g. read an exposition
> on the topic in a wiki page, listen to some music, create an e-toy
> project, answer some questions, ...). Moodle provides the teacher with a
> wealth of information on the progress of each student.
>
> This organization suggests that course developers could start a new
> course or add sections to an existing course or add activities to an
> existing section. It also suggests that teachers in a local community
> could 'cut and paste' a course from these elements, adding or modifying
> as needed.
>
> The moderators would be new element. In the case of the Saturday Academy
> courses, they could be the 'teacher' working with a 'cohort' of enrolled
> students, who could be anywhere in the world. In the case of 'core'
> courses, they could provide help to the classroom teacher as well as
> helping to mentor students at the invitation of the teacher. For
> example, a class in Rwanda studying English could ask a moderator who is
> a native English speaker to meet with them at a specified time to tell
> them a story or host a chat. The teacher could ask the moderator to
> review student submissions (recorded audio or written material) for
> appropriate pronunciation or use of the language.
>
> The primary problem with Moodle at the moment is that there are is not a
> body of grade school courses available to illustrate how to build them
> or to provoke the community to 'make it better'. Unfortunately, at the
> moment, many people in the community do not consider the schoolserver to
> be essential, existing Moodle courses are primarily aimed at the
> university or pre-university level, and most of these are behind
> proprietary walls.
>
> Tony
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
--
Caroline Meeks
Solution Grove
Caroline at SolutionGrove.com
617-500-3488 - Office
505-213-3268 - Fax
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090103/d826d1c0/attachment-0001.htm
From walter.bender at gmail.com Sat Jan 3 09:05:55 2009
From: walter.bender at gmail.com (Walter Bender)
Date: Sat, 3 Jan 2009 09:05:55 -0500
Subject: [Sugar-devel] TA with sensors
In-Reply-To: <242851610901030148m2f013e2fw2483aa5c52e0258d@mail.gmail.com>
References:
<242851610901030148m2f013e2fw2483aa5c52e0258d@mail.gmail.com>
Message-ID:
Thanks. I'll give it a try.
-walter
On Sat, Jan 3, 2009 at 4:48 AM, Tomeu Vizoso wrote:
> Also, see the link below for a way to detect when the activity window
> is visible or not:
>
> http://git.sugarlabs.org/projects/sugar/repos/mainline/blobs/master/src/jarabe/journal/journalactivity.py#line298
>
> It's used by the journal in order to decide whether it needs to auto
> refresh its view or not.
>
> Regards,
>
> Tomeu
>
> On Sat, Jan 3, 2009 at 05:19, Arjun Sarwal wrote:
>> On Sat, Jan 3, 2009 at 1:18 AM, Walter Bender wrote:
>>> Thanks for this background.
>>>
>>> I think that the try/exception mechanism is adequate for our needs. It
>>> will be otherwise trivial for me to add the sensor features to the
>>> main branch of TA... I'll add it to the next release.
>>>
>>> I wonder if there is a mechanism we can call upon (Sugar should
>>> perhaps provide this) that will tell us that we are being sent to the
>>> background so that we can only reinitialize when we go away and come
>>> back? It seems that for every call to the sensor, it is a large
>>> overhead to incur...
>>>
>>
>> There are signals in Sugar that are fired when an Activity becomes the
>> background Activity or foreground Activity (I've used these in Measure
>> code). It seems like a good idea to explore to keep the capture device
>> ON while TurtleArt is the active Activity and leave the audio device
>> when Activity is in background and then re-initialize it when
>> TurtleArt becomes the active Activity.
>>
>>> -walter
>>>
>>> On Fri, Jan 2, 2009 at 2:25 PM, Arjun Sarwal wrote:
>>>> Hello Walter,
>>>>
>>>> Thank you for the new year wishes. Best wishes to you too for the new
>>>> year! (hope you received my card too)
>>>>
>>>> A few points regarding adding sensor support
>>>>
>>>> * Calls to Alsamixer to set the DC mode on/off will result in an
>>>> exception on one's normal laptop. This is because the DC mode controls
>>>> don't exist in the Alsamixer of a normal laptop (even sugar emulation
>>>> makes calls to the laptop's default alsamixer)
>>>>
>>>> * I had put in initializations before each call to the sensor because
>>>> - user may switch to another Activity in between a session of Turtle
>>>> Art -- the other Activity may use the laptop's sound device. The
>>>> other Activity may alter the sound device settings.
>>>> - unless a call for sensor input is being made, I didn't want to keep
>>>> the capture device active.
>>>> The capture device can be thought to be in a state of 'recording
>>>> sound' when one is getting sensor input data, hence only one
>>>> Activity/program can have access to it at one time.
>>>> However, any suggestions you may have on the above implementation
>>>> would be very welcome.
>>>>
>>>>
>>>> * If it helps, I am summarizing approximately the changes I made in
>>>> TurtleArt to add sensor support and some relevant lines to look at
>>>> within the TA with Sensors code that I had made for the earlier (non
>>>> SVG version of TAwithSensors):
>>>> Referring to the version of the online git tree ('Initial import')
>>>> (http://dev.laptop.org/git?p=users/arjs/TurtleArtwithSensors;a=tree;h=3f22f9f86d60f6160268c52009273eba82dba465;hb=3f22f9f86d60f6160268c52009273eba82dba465)
>>>>
>>>> - audiograb.py as an additional file was included completely
>>>> - talogo.py :
>>>> (note that lines 8 and 9 in this version of git tree would need to be
>>>> changed to
>>>> from numpy.oldnumeric import *
>>>> from numpy.fft import * )
>>>> lines 8,9,11,12 were added
>>>> lines 366 onwards till the end have been added
>>>> -tasetup.py: lines 47 to 51 to account for the additional sensor
>>>> blocks in the UI
>>>>
>>>> As you can see from the code of talogo.py , the approach involves a
>>>> lot of painful starting the whole gstreamer pipeline, getting one
>>>> sample then stopping the pipeline. An overkill for getting just one
>>>> sample, but there is no way unless python alsa audio is included in
>>>> the build system. The approach with python alsa audio is work in
>>>> progress here (
>>>> http://dev.laptop.org/git?p=users/arjs/TurtleArtwithSensors;a=tree )
>>>>
>>>> I want to work on incorporating sensor support into the SVG version of
>>>> TA that you have made, but my current day job isn't leaving me any
>>>> time these days to do anything else. I will get to it as soon as I get
>>>> the opportunity, but if in the meanwhile you get a chance to do it -
>>>> it'd be great.
>>>>
>>>> Please let me know if I can help further.
>>>>
>>>> Kind Regards
>>>> Arjun
>>>>
>>>> On Fri, Jan 2, 2009 at 3:18 AM, Walter Bender wrote:
>>>>>
>>>>> I've begun folding TA with sensors into TA. I use an exception to
>>>>> catch the calls to set DC Mode in Alsamixer, so it seems to run fine
>>>>> on my normal laptop using the mic input. But when I look at the logs,
>>>>> it seems that there is a lot of initialization that happens with every
>>>>> call to the sensor. Is that all necessary? Can we just check for
>>>>> changes after the first time?
>>>>>
>>>>> -walter
>>>>>
>>>>>
>>>>>
>>>>> # test to see if DC Mode is enabled
>>>>> try:
>>>>> self.dcmode = Mixer('DC Mode Enable')
>>>>> self.bias = Mixer('V_REFOUT Enable')
>>>>> self.has_dcmode = True
>>>>> except:
>>>>> print "DC Mode unavailable"
>>>>> self.has_dcmode = False
>>>>>
>>>>>
>>>>>
>>>>> Walter Bender
>>>>> Sugar Labs
>>>>> http://www.sugarlabs.org
>>>>
>>>>
>>>>
>>>> --
>>>> Arjun Sarwal
>>>>
>>>
>>>
>>>
>>> --
>>> Walter Bender
>>> Sugar Labs
>>> http://www.sugarlabs.org
>>>
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
--
Walter Bender
Sugar Labs
http://www.sugarlabs.org
From tony_anderson at usa.net Sat Jan 3 09:23:43 2009
From: tony_anderson at usa.net (Tony Anderson)
Date: Sat, 03 Jan 2009 09:23:43 -0500
Subject: [Sugar-devel] [Fwd: Re: Education on the XO]
Message-ID: <495F74EF.8020009@usa.net>
Hi,
I don't know Merlot. There is a lot of good ingredients in the Connexion
site at Rice. Sadly, there is a tremendous body of good ingredients, but
all copyrighted. I think in many cases the copyright is not done to
restrict use of the materials, but because it is automatic. However,
that poses a major hurdle in using the material.
The question of partners is central (and the reason I raised the issue).
I would think Sugar Labs are an option. The Moodle organization is an
option. However, even there the only 'free' course example I could find
was the 'Features Demo'.
So far as I can tell, the countries are tied up trying to solve
immediate deployment problems. While there is a lot of good work being
done, it is not easily accessible as ingredients for course building.
I would appreciate any ideas you have on how to proceed.
Thanks,
Tony
Caroline Meeks wrote:
> Hi Tony,
>
> I agree that content and activities that are delivered via Moodle should
> be an important part of this project. Have you done any research into
> what content is currently available? Who do you think are our best
> partners for creating and maintaining a collection of K-8 resources that
> can be accessed via Moodle? Curriki? Merlot? Which countries are
> ahead in this?
>
> Thanks,
> Caroline
>
> On Sat, Jan 3, 2009 at 7:31 AM, Tony Anderson > wrote:
>
> Bryan has started a very interesting discussion about what is needed for
> the XO to support education. I would like to add my two cents worth.
>
> We are learning (gaining new experience) every day that we are alive.
> The traditional difference in education is that it is organized
> learning. Teaching a topic means to provide an organized tour of an area
> of knowledge covering what every student should know or be aware of.
>
> The XO's primary tool for education, as opposed to learning experiences,
> is Moodle. The problem is that Moodle for the XO is a tool which is
> ready and waiting to be used (all dressed up and no where to go).
>
> My vision is that there is a repository (website) which contains free
> (CC or similar) courses covering the core curriculum for K-8. The
> website needs to be supported by a community of developers (course
> creators) and moderators (folks who volunteer to assist teachers and
> students who are participating). This repository should also contain
> 'elective' courses following the model of Oregon's Saturday Academy
> (http://www.saturdayacademy.org/).
>
> A Moodle course is divided into sections (topics, weeks, ...). Each
> section has one or more 'activities' (a word which is very heavily
> overloaded). Essentially an 'activity' here is something the course
> creator asks the students to do or experience (e.g. read an exposition
> on the topic in a wiki page, listen to some music, create an e-toy
> project, answer some questions, ...). Moodle provides the teacher with a
> wealth of information on the progress of each student.
>
> This organization suggests that course developers could start a new
> course or add sections to an existing course or add activities to an
> existing section. It also suggests that teachers in a local community
> could 'cut and paste' a course from these elements, adding or modifying
> as needed.
>
> The moderators would be new element. In the case of the Saturday Academy
> courses, they could be the 'teacher' working with a 'cohort' of enrolled
> students, who could be anywhere in the world. In the case of 'core'
> courses, they could provide help to the classroom teacher as well as
> helping to mentor students at the invitation of the teacher. For
> example, a class in Rwanda studying English could ask a moderator who is
> a native English speaker to meet with them at a specified time to tell
> them a story or host a chat. The teacher could ask the moderator to
> review student submissions (recorded audio or written material) for
> appropriate pronunciation or use of the language.
>
> The primary problem with Moodle at the moment is that there are is not a
> body of grade school courses available to illustrate how to build them
> or to provoke the community to 'make it better'. Unfortunately, at the
> moment, many people in the community do not consider the schoolserver to
> be essential, existing Moodle courses are primarily aimed at the
> university or pre-university level, and most of these are behind
> proprietary walls.
>
> Tony
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
>
>
> --
> Caroline Meeks
> Solution Grove
> Caroline at SolutionGrove.com
>
> 617-500-3488 - Office
> 505-213-3268 - Fax
From walter.bender at gmail.com Sat Jan 3 09:23:51 2009
From: walter.bender at gmail.com (Walter Bender)
Date: Sat, 3 Jan 2009 09:23:51 -0500
Subject: [Sugar-devel] Teaching typing and basic math on the XO
In-Reply-To: <7087c32a0901021742i49aaa97rd70d2a8992e8b217@mail.gmail.com>
References: <1230874359.17108.16.camel@hitman>
<1230923827.17108.65.camel@hitman>
<7087c32a0901021154r506f1f76k8b61cb0a68b2c672@mail.gmail.com>
<1230927010.17108.103.camel@hitman>
<20090102235506.GA23251@twin.sascha.silbe.org>
<7087c32a0901021620t76f42fcele8c97ed01cedc3d8@mail.gmail.com>
<20090103003834.GB23251@twin.sascha.silbe.org>
<7087c32a0901021742i49aaa97rd70d2a8992e8b217@mail.gmail.com>
Message-ID:
One though--inspired by your earlier comment about how a purely
constructionist approach would say that they'll learn to type when
they use write or chat: Activities like Memorize and JigSawPuzzle let
the learners play right away but also have game-construction features
built in. It might be fun to think of ways in which the typing tutor
could be modified either by the teacher or the children as part of the
process or to capture data in interesting ways. I don't have any
non-obvious ideas off the top of my head but something to consider.
(races over the mesh, customizable strings, sounds, images, etc.
Plotting statistics in Measure, etc.)
-walter
On Fri, Jan 2, 2009 at 8:42 PM, Wade Brainerd wrote:
> I'm following the format used by programs like MicroType and Mavis Beacon
> Teaches Typing (what I personally learned on). Both have demo versions for
> Windows available.
>
> TT will be simple compared with these programs, but they are the general
> template.
>
> We are working towards an alpha in early January.. When it's ready I will
> announce it on the sugar list.
>
> Cheers,
> Wade
>
> On Fri, Jan 2, 2009 at 7:38 PM, Sascha Silbe
> wrote:
>>
>> On Fri, Jan 02, 2009 at 07:20:05PM -0500, Wade Brainerd wrote:
>>
>>> If you have used TuxType, you will know that it's a simplistic typing
>>> *practice game* and in no way teaches the user how to type.
>>
>> I thought that's what you're looking for. How do you imagine a "typing
>> teaching activity" to work?
>> What does the "Typing Turtle" activity that was mentioned look like?
>>
>> CU Sascha
>>
>> --
>> http://sascha.silbe.org/
>> http://www.infra-silbe.de/
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.6 (GNU/Linux)
>>
>> iQEVAwUBSV6zirpz82VMF3DaAQLpMwgArkQogjN/D+9IUvqvbHlXaduKF6UMaxfg
>> JIfTIbdTccjCxuXzqMv90hrFCXEg1stiXqgaWjZpCX5JN+WjDkSQPYxY2oeQQOZj
>> 0+TiYbsLwWFOUXPlJkfiJpKXVH+cOu0et5ZIqSPd84MyekxtGqCyb0sd/uKCcu09
>> zr7Ri2ADoQoq1p1XI38m/IqCRyiDtpez9UX8AB2L48tDD15Yhlnh0QMy7EuhYMli
>> ZhtW1Ng33pWV9diYkjawmD8vs+rniFtcXKW/IZG63LOV5UZ66eMEGx6CAKV9TXNp
>> jOjPW9L5oUZLh0/Cb1hFvKYRzzDuLKijdNcvYWfRKw8Bv0MrkhmOAg==
>> =7WVV
>> -----END PGP SIGNATURE-----
>>
>
>
--
Walter Bender
Sugar Labs
http://www.sugarlabs.org
From jns-cmarshall at comcast.net Sat Jan 3 10:47:28 2009
From: jns-cmarshall at comcast.net (Chris Marshall)
Date: Sat, 03 Jan 2009 10:47:28 -0500
Subject: [Sugar-devel] Education on the XO
In-Reply-To: <495F5AB6.2060806@usa.net>
References: <495F5AB6.2060806@usa.net>
Message-ID: <495F8890.2070409@comcast.net>
It would help if there were a Moodle connection
for G1G1 XO-ers. From my limited reading it
appears that Moodle is tied in with the XS which
means that a G1G1 laptop owner will have no
easy way to get started or even to discover the
availability or applicability of Moodle.
As one example, I've shown a number of teachers
the XO and they were very interested to see the
laptop. The case would have been *far* more
compelling if I had been able to show them more
of a classroom use case.
Some thoughts:
(1) Develop a Moodle activity to let XO users
create courseware without a full XS
(2) Make a mini-LiveCD of the XS to support
Moodle course development and testing.
(3) Is Birmingham using Moodle? I've done
periodic Googles with no real information
on progress, XO usage, ...
--Chris
Tony Anderson wrote:
>
> The XO's primary tool for education, as opposed to learning experiences,
> is Moodle. The problem is that Moodle for the XO is a tool which is
> ready and waiting to be used (all dressed up and no where to go).
>
> ...snip...
>
> The primary problem with Moodle at the moment is that there are is not a
> body of grade school courses available to illustrate how to build them
> or to provoke the community to 'make it better'. Unfortunately, at the
> moment, many people in the community do not consider the schoolserver to
> be essential, existing Moodle courses are primarily aimed at the
> university or pre-university level, and most of these are behind
> proprietary walls.
From dfarning at sugarlabs.org Sat Jan 3 11:24:21 2009
From: dfarning at sugarlabs.org (David Farning)
Date: Sun, 4 Jan 2009 10:24:21 +1800
Subject: [Sugar-devel] Education on the XO
In-Reply-To: <495F8890.2070409@comcast.net>
References: <495F5AB6.2060806@usa.net> <495F8890.2070409@comcast.net>
Message-ID:
Chris,
Is this something that you would be able to look into more deeply?
Sugar Labs has a moodle server at schools.sugarlabs.org . But, we
don't have anyone with the time and skills to champion the effort yet.
There are a lot of interest people! No one with a knowledge of Sugar,
Moodle, and content development.... and enough passion led craziness
has volunteered to coordinate the effort:(
david
On Sun, Jan 4, 2009 at 9:47 AM, Chris Marshall
wrote:
> It would help if there were a Moodle connection
> for G1G1 XO-ers. From my limited reading it
> appears that Moodle is tied in with the XS which
> means that a G1G1 laptop owner will have no
> easy way to get started or even to discover the
> availability or applicability of Moodle.
>
> As one example, I've shown a number of teachers
> the XO and they were very interested to see the
> laptop. The case would have been *far* more
> compelling if I had been able to show them more
> of a classroom use case.
>
> Some thoughts:
>
> (1) Develop a Moodle activity to let XO users
> create courseware without a full XS
>
> (2) Make a mini-LiveCD of the XS to support
> Moodle course development and testing.
>
> (3) Is Birmingham using Moodle? I've done
> periodic Googles with no real information
> on progress, XO usage, ...
>
> --Chris
>
> Tony Anderson wrote:
>>
>> The XO's primary tool for education, as opposed to learning experiences,
>> is Moodle. The problem is that Moodle for the XO is a tool which is
>> ready and waiting to be used (all dressed up and no where to go).
>>
>> ...snip...
>>
>> The primary problem with Moodle at the moment is that there are is not a
>> body of grade school courses available to illustrate how to build them
>> or to provoke the community to 'make it better'. Unfortunately, at the
>> moment, many people in the community do not consider the schoolserver to
>> be essential, existing Moodle courses are primarily aimed at the
>> university or pre-university level, and most of these are behind
>> proprietary walls.
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
From tony_anderson at usa.net Sat Jan 3 11:50:55 2009
From: tony_anderson at usa.net (Tony Anderson)
Date: Sat, 03 Jan 2009 11:50:55 -0500
Subject: [Sugar-devel] Education on the XO
In-Reply-To: <495F8890.2070409@comcast.net>
References: <495F5AB6.2060806@usa.net> <495F8890.2070409@comcast.net>
Message-ID: <495F976F.80002@usa.net>
Hi,
Creating a Moodle site is quite easy - see http://moodle.org/. It does
not require the schoolserver.
OLENepal has created a livecd version of XS based on XS-0.4 (see
http://wiki.laptop.org/go/OLE_Nepal:Schoolserver)
Clearly, two things are needed. One, a Moodle site for the XO. Two, a
set of courses on the site aimed at K-8.
Hopefully in the next two months, we will be able to put the existing
Nepal course materials online in the form of Moodle courses.
Tony
Chris Marshall wrote:
> It would help if there were a Moodle connection
> for G1G1 XO-ers. From my limited reading it
> appears that Moodle is tied in with the XS which
> means that a G1G1 laptop owner will have no
> easy way to get started or even to discover the
> availability or applicability of Moodle.
>
> As one example, I've shown a number of teachers
> the XO and they were very interested to see the
> laptop. The case would have been *far* more
> compelling if I had been able to show them more
> of a classroom use case.
>
> Some thoughts:
>
> (1) Develop a Moodle activity to let XO users
> create courseware without a full XS
>
> (2) Make a mini-LiveCD of the XS to support
> Moodle course development and testing.
>
> (3) Is Birmingham using Moodle? I've done
> periodic Googles with no real information
> on progress, XO usage, ...
>
> --Chris
>
> Tony Anderson wrote:
>>
>> The XO's primary tool for education, as opposed to learning
>> experiences, is Moodle. The problem is that Moodle for the XO is a
>> tool which is ready and waiting to be used (all dressed up and no
>> where to go).
>>
>> ...snip...
>>
>> The primary problem with Moodle at the moment is that there are is not
>> a body of grade school courses available to illustrate how to build
>> them or to provoke the community to 'make it better'. Unfortunately,
>> at the moment, many people in the community do not consider the
>> schoolserver to be essential, existing Moodle courses are primarily
>> aimed at the university or pre-university level, and most of these are
>> behind proprietary walls.
>
> .
>
From jns-cmarshall at comcast.net Sat Jan 3 13:33:27 2009
From: jns-cmarshall at comcast.net (Chris Marshall)
Date: Sat, 03 Jan 2009 13:33:27 -0500
Subject: [Sugar-devel] Education on the XO
In-Reply-To:
References: <495F5AB6.2060806@usa.net> <495F8890.2070409@comcast.net>
Message-ID: <495FAF77.7010004@comcast.net>
Sorry, I am unable to take on this task.
I will continue to follow the thread and
participate as I can.
Regards,
Chris
David Farning wrote:
> Chris,
>
> Is this something that you would be able to look into more deeply?
> Sugar Labs has a moodle server at schools.sugarlabs.org . But, we
> don't have anyone with the time and skills to champion the effort yet.
>
> There are a lot of interest people! No one with a knowledge of Sugar,
> Moodle, and content development.... and enough passion led craziness
> has volunteered to coordinate the effort:(
>
> david
>
> On Sun, Jan 4, 2009 at 9:47 AM, Chris Marshall
> wrote:
>> It would help if there were a Moodle connection
>> for G1G1 XO-ers. From my limited reading it
>> appears that Moodle is tied in with the XS which
>> means that a G1G1 laptop owner will have no
>> easy way to get started or even to discover the
>> availability or applicability of Moodle.
>>
>> As one example, I've shown a number of teachers
>> the XO and they were very interested to see the
>> laptop. The case would have been *far* more
>> compelling if I had been able to show them more
>> of a classroom use case.
>>
>> Some thoughts:
>>
>> (1) Develop a Moodle activity to let XO users
>> create courseware without a full XS
>>
>> (2) Make a mini-LiveCD of the XS to support
>> Moodle course development and testing.
>>
>> (3) Is Birmingham using Moodle? I've done
>> periodic Googles with no real information
>> on progress, XO usage, ...
>>
>> --Chris
>>
>> Tony Anderson wrote:
>>> The XO's primary tool for education, as opposed to learning experiences,
>>> is Moodle. The problem is that Moodle for the XO is a tool which is
>>> ready and waiting to be used (all dressed up and no where to go).
>>>
>>> ...snip...
>>>
>>> The primary problem with Moodle at the moment is that there are is not a
>>> body of grade school courses available to illustrate how to build them
>>> or to provoke the community to 'make it better'. Unfortunately, at the
>>> moment, many people in the community do not consider the schoolserver to
>>> be essential, existing Moodle courses are primarily aimed at the
>>> university or pre-university level, and most of these are behind
>>> proprietary walls.
From bryan at olenepal.org Sat Jan 3 13:57:13 2009
From: bryan at olenepal.org (Bryan Berry)
Date: Sat, 03 Jan 2009 10:57:13 -0800
Subject: [Sugar-devel] web-based activities (was Re: [IAEP] How to Make
Activity Designers Happy , Parts I and II)
In-Reply-To: <242851610901030126t1894ef2am6bcb0232be625d4@mail.gmail.com>
References: <242851610901021018r4c84d249r8b348dc126c4bbe9@mail.gmail.com>
<1230924646.17108.76.camel@hitman>
<242851610901030126t1894ef2am6bcb0232be625d4@mail.gmail.com>
Message-ID: <1231009033.32208.63.camel@hitman>
On Sat, 2009-01-03 at 10:26 +0100, Tomeu Vizoso wrote:
> On Fri, Jan 2, 2009 at 20:30, Bryan Berry wrote:
> > On Fri, 2009-01-02 at 19:18 +0100, Tomeu Vizoso wrote:
> >> Hi,
> >>
> >> without needing to get into what is better for our deployments, I do
> >> see value in making easier to make Sugar activities using technologies
> >> such as HTML, CSS, etc
> >> Bryan, can we get into a more detailed view on what it would take
> >> ideally to create a new activity using such activities? Which would be
> >> the steps that an experienced web designer would need to take in order
> >> to create a Sugar activity?
> >
> > Presently, we do the following to run flash activities on the XO
> >
> > 1) download the Firefox3.xo bundle
> > 2) change the activity.info file
> > 3) change some of the file and directory names to reference
> > EPaathActivity instead of FirefoxActivity
> > 4) copy the swf (flash) files to ./activity/Activity/Activities (I know
> > it's ugly
> > 5) change the firefoxactivity.py
> > ff = [ './firefox' ]
> > to
> > ff = [ './firefox', './activity/Activity/Activities/OurSWF.htm']
>
> Doesn't sound too complicated. How is it working right now? Which are
> the biggest issues? How do you envision this should be done instead?
The biggest issue we have is that Browse doesn't support tabs and that
it is a pain to read a pdf document inside of Browse or launch it from
Firefox3. We are using Firefox 3 but some unpleasant stuff happens when
we launch a new full-screen window. Most unpleasant is that the new
window can't be killed from Sugar.
> >> I'm sure that someone with basic knowledge of python could create some
> >> tools that make it much more easier than it is today. Also have some
> >> ideas about how those activities could interact with the journal and
> >> other Sugar features.
Agreed. It would be particularly useful for python testing tools that a
flash or javascript developer could use to tell if his activity will run
properly on the XO according to simple metrics. Those metrics would be
1) audio file not too large 2) activity fits w/in XO screen resolution.
3) animation not heavy for the XO. Additionally, all activity designers
need better tools to tell them if their xo bundle is properly formed.
> >> Thanks,
> >>
> >> Tomeu
> >
> > Again, this requires people to learn python, a whole new language that
> > they don't necessarily use at work. We need to enable developers to be
> > very productive in just 2-3 hours per week. For them to be productive
> > they need to be using tools they are already familiar w/.
> >
> > Python is a tool popular among sysadmins and hackers. It is great tool.
> > But folks who develop web UIs use css, html, javascript, and flash. I
> > highly doubt that will change in the near or distant future. These are
> > people we need to recruit as activity designers.
>
> I guess I was unclear in my proposal. What I was talking about is
> creating a set of tools that the web developers would use. A python
> coder would write and maintain them and the web developers would use
> them to deploy their work.
>
> Regards,
>
> Tomeu
>
> >> On Fri, Jan 2, 2009 at 02:50, Bryan Berry wrote:
> >> > This is a draft of a multi-part article I plan to post to OLPC News.
> >> >
> >> > It is very long but I would very much appreciate your opinions and
> >> > feedback. Your input will make it a better article once published.
> >> >
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >
> >> > This OLPC project seems to be going pretty well as of late December
> >> > 2008. G1G1 v2 is well underway, there are a number of successful pilots
> >> > going on, and a number of larger-scale pilots will come online this
> >> > spring and coming summer.
> >> >
> >> > Still, there is a big gaping whole in the middle of our little education
> >> > project. There just aren't enough activities. Mind you, we have some
> >> > seriously awesome activities such as Etoys, Scratch, TamTam, and others.
> >> > We have tremendous depth but very limited breadth.
> >> >
> >> > By breadth, I mean interactive activities for language, history,
> >> > geology, health, etc. In order to expand the range of activities, we
> >> > need to recruit a lot more activity developers and make it dead-simple
> >> > for them to contribute.
> >> >
> >> > But Which Developers?
> >> >
> >> > Let's think about who we want to recruit. We're talking about breadth
> >> > here so we need experts on Nepali grammar, Pashto vocabulary, Philippine
> >> > history, and Andean geography. The good news is that there are
> >> > technically-oriented people out there that know these things and want to
> >> > help.
> >> >
> >> > We already have a hardcore team of dedicated hackers. We need them for
> >> > the work that hackers excel at: building infrastructure, testing the
> >> > limits of new systems. But now we need a different class of developer,
> >> > those that are focused on the presentation, game play and not system
> >> > internals.
> >> >
> >> > Based on these characteristics, let's call these people
> >> > designers. The good news is that there are lots of
> >> > designers-particularly in developing countries-that want to contribute
> >> > to OLPC. The bad news is that they don't know python. or GTK+. They may
> >> > not even be familiar with linux. They do know HTML, CSS, Javascript, and
> >> > Adobe Flash. Allow me to explain.
> >> >
> >> > Due to rise of the Internet and related boom in outsourcing, the vast,
> >> > vast majority of programmers in developing countries are web developers
> >> > (according to my own grossly unscientific survey). The rise of the
> >> > Internet has also led a lot of talented graphic designers in developing
> >> > and developed countries to learn web technologies. I even
> >> > wager that CSS/HTML/Javascript will become the de facto GUI technologies
> >> > in a few years time. >> > href="http://en.wikipedia.org/wiki/Pygtk">PyGTK won't take over the
> >> > world nor will VB.net.
> >> >
> >> > The popular term for this triumvirate of technologies is >> > href="http://en.wikipedia.org/wiki/AJAX">AJAX, with the difference
> >> > that AJAX applications typically require communication with a remote
> >> > server. I propose using web technologies for completely offline
> >> > activities. Adobe's Flash is basically a variant of AJAX that uses
> >> > dialects of Javascript ( >> > href="http://en.wikipedia.org/wiki/Actionscript">Actionscript) and
> >> > XML (MXML).
> >> >
> >> > Very few programmers in the developed world get paid to write desktop
> >> > linux apps. Still, open-source developers find learn and build pygtk,
> >> > mono, and KDE apps in their free-time. Developers in the developing
> >> > world are extremely enthusiastic about FOSS but not nearly as prolific
> >> > in creating open-source software due to a phenomenon I
> >> > call the "FOSS-Nepal Paradox."
> >> >
> >> > The >> > href="http://wiki.fossnepal.org/index.php?title=The_FOSS_Nepal_Community">FOSS Nepal community has won the award for best celebration of Software Freedom day for two years in a running. Despite all this enthusiasm the FOSS Nepal community is not very prolific in producing open-source code. The reason for this is that Nepal is not a wealthy country and that Open-Source is expensive to produce.
> >> >
> >> > Open-Source is Expensive
> >> >
> >> > Open-source software voraciously consumes a resource even more valuable
> >> > than hard cash, programmer time. Linus Torvalds could afford to spend
> >> > some of the most productive years of his life working without immediate
> >> > financial benefit. He could slack off in his classes without fear of
> >> > unemployment upon graduation. I doubt his parents were counting on him
> >> > to support them financially once he got a job.
> >> >
> >> > Most talented Nepali programmers I know do not have those luxuries. They
> >> > are under a lot of pressure to support their parents and extended
> >> > families, financially and otherwise. So Nepalis, Bangladeshis, Peruanos,
> >> > etc. certainly have the passion and ability to contribute to open-source
> >> > but their free time is significantly more limited.
> >> >
> >> > This doesn't mean that we should rely on developers from rich countries.
> >> > We simply need to radically lower the amount of time required to create
> >> > learning activities. I believe that many, many developers in the
> >> > developing world can contribute 3-5 hours per week. To make those few
> >> > hours productive we need to rework the default activity framework.
> >> >
> >> > >From what I can tell, the primary design goals of the default PyGTK
> >> > activity
> >> > framework are as follows:
> >> >
> >> > - Give the programmer maximum flexibility
- Fully exploit
> >> > the XO's hardware features
- Mesh nicely with Sugar
> >> >
> >> > These three goals are laudable and their hacker roots are obvious. The
> >> > problem is that these goals maximize the technology's potential rather
> >> > than programmer productivity. We need reach beyond the vi/emacs crowd
> >> > (Note: I wrote this article using emacs) to thos folks that the masters
> >> > of Photoshop, Adobe Illustrator, Eclipse, and GIMP.
> >> >
> >> > I propose a new set of design goals:
> >> >
> >> >
> >> > - Allow activity designers to quickly build activities utilizing
> >> > widely-used tools.
> >> > - Quickly reward effort with working behavior
> >> > - Mesh nicely with the Sugar UI
> >> >
> >> >
> >> > It's OK to be Opinionated
> >> >
> >> > We need an opinionated activity framework that makes infrastructure
> >> > choices for the designer so that she can focus presentation and
> >> > gameplay. Some may recognize this as the principle of >> > href="http://en.wikipedia.org/wiki/Convention_over_Configuration">Convention Over Configuration, a principle that two of the most popular web frameworks, Django and RubyOnRails, adhere to. Now a lot of geeks don't like Convention over Configuration--perl hackers especially--but they sure do allow you to create nice applications very quickly.
> >> >
> >> > Establishing an "opinionated" activity framework will in no way limit
> >> > the freedom of those hackers who want to go their own way. They can
> >> > always build their own activities from whatever tools they choose. The
> >> > whole point of a framework is to help people get started quickly but it
> >> > doesn't constrain anyone.
> >> >
> >> > This concludes part I. Here are some tantalizing morsels from Part II
> >> > of "How to Make Activity Designers Happy,"
> >> >
> >> >
> >> > - Where it's at: HTML, CSS, Javascript, and *gasp* Flash
> >> > - Nepal's Content Development Experience
> >> > - Aren't Kids going to create all learning activities so we don't
> >> > have to?
> >> >
> >> >
> >> >
> >> > Bryan Berry is the Technology Director of >> > href="http://www.olenepal.org">OLE Nepal and deadbeat co-editor of
> >> > OLPCNews.com. Christopher Marin contributed his knowledge about all
> >> > things web to this article
> >> >
> >> >
> >> >
> >> > In part 1, I talked about the paradoxical
> >> > nature of open-source communities in developing countries, flaws in
> >> > the current default activity development framework, and the urgent
> >> > need for a new framework that makes activity designers happy.
> >> >
> >> > By happy, I mean that the framework rewards their efforts almost
> >> > immediately (roughly 15 minutes of effort) and it lets them focus on
> >> > presentation and gameplay rather than infrastructure. Last time I
> >> > offered some vague ideas how this framework might function. This time
> >> > I will provide more details how this framework could work and why.
> >> >
> >> > Let's Ride The Internet Wave
> >> >
> >> > The Internet is the 300-pound gorilla in the software-engineering room
> >> > it will eat virtually everything, including your favorite desktop GUI
> >> > framework. All of the IDE's bend over backwards to support coding of
> >> > webapps, whether it is emacs, eclipse, or even vim. The software
> >> > industry is making huge investments into web technologies that support
> >> > the triumvirate of HTML/CSS/Javascript, witness Google's investment in
> >> > V8 javascript compiler and
> >> > Apple's investment in >> > href="http://en.wikipedia.org/wiki/WebKit">Webkit. I speculate
> >> > that there are many, many more developers working on GUI toolkits for
> >> > the web browser- such as JQuery, Prototype, Script.aculo.us-than for
> >> > GNOME or KDE desktop frameworks.
> >> >
> >> > The web will keep innovating at a breakneck pace. We need to ride that
> >> > wave of innovation.
> >> >
> >> > In the early days of OLPC, we all had a lot of grandiose and
> >> > impractical ideas. The educational systems of developing countries
> >> > would change overnight into constructionist hotbeds. Kids would build
> >> > their own activities, eliminating the need for large investments in
> >> > content development. A million PyGTK apps with built-in collaboration
> >> > and "View-Source" key would spontaneously bloom . . . Well, we're
> >> > older and wiser now. School systems anywhere are not blank slates that
> >> > we can redraw from scratch using cheap laptops and Etoys. Similarly,
> >> > we cannot expect thousands of developers to flock to a framework
> >> > (PyGTK) that is not commercially popular.
> >> >
> >> > Developing Country Developer Economics
> >> >
> >> > As I wrote in Part I, the economics of open-source in developing
> >> > countries is quite different than that in the developed
> >> > world. Developers there have ample enthusiasm for open-source but much
> >> > less time to contribute.
> >> >
> >> > We need to lower the barrier of entry significantly in order to use
> >> > their talents. In fact, we need to entice non-programmers such as
> >> > graphic designers. In my limited experience, graphic designers are
> >> > much better at designing learning activities than programmers. They
> >> > better appreciate aesthetics and visual story-telling.
> >> >
> >> > Web designers layout their work using CSS and (X)HTML. They implement
> >> > user interaction and animations using Javascript. They design their
> >> > work using Photoshop, GIMP, Adobe Illustrator, and sometimes
> >> > Eclipse. They know the features and dark areas of the Firefox web
> >> > browser. Sugar infrastructure developers, these people are your
> >> > customers. We need KARMA to enable them to quickly buidl activities
> >> > for the XO without having to learn a whole new skillset. From a
> >> > programmatic point of view, Browse needs to behave as much as possible
> >> > like Firefox. Any discrepancy will distract activity designers from
> >> > the more rewarding parts of activity development.
> >> >
> >> > Building Good KARMA
> >> >
> >> > Before we get too far, let's give this new activity framework a name
> >> > so I can save us all a lot of excess verbiage. I call it KARMA,
> >> > because the word is loosely-related to Nepal, my current residence,
> >> > and I like to think creating open-source learning activities gives an
> >> > individual good karma. Coincidentally, it is also the first two
> >> > syllables of Rabi Karmacharya's last name--an individual put a ton of
> >> > hard work and personal sacrifice into the OLPC project in Nepal.
> >> >
> >> > Well, I haven't actually made up my mind what the core technologies of
> >> > KARMA
> >> > should be. I need your help to work it out. Before I get into the
> >> > technologies, here are my priorities. 1) These tools maximize
> >> > programmer productivity and 2) are open-soure. Priority #1 is much
> >> > more important than #2. 100% purely open-source activities that don't
> >> > exist don't help kids learn. The current pygtk framework is purely
> >> > open-source but you have to become a unix programmer to use it. As I
> >> > noted in Part I, the vast, vast majority of programmers in the
> >> > developing world are web developers and a successful activity
> >> > framework will allow them to re-use their existing skills and tools.
> >> >
> >> > I have settled on HTML and CSS for the presentation but it is tougher
> >> > to decide on the scripting toolset and on persistent data
> >> > storage. Flash handles animations really well and it is easy to
> >> > integrate audio into the animations. Adobe sells some really nice
> >> > WYSIWYG tools for editing animation and adding audio. A lot of
> >> > developers know flash so there is a large pool of talent we can draw
> >> > from. Did I forget to mention that Flash is proprietary?
> >> >
> >> > The closed-source issue not withstanding, Flash is the tool to
> >> > use. Some may be upset that Flash doesn't lend itself to "View Source"
> >> > functionality but learning programming is not the sum total of
> >> > education. Kids can do all the programming they ever want to w/ the
> >> > excellent Etoys and Scratch. Sorry to sound like a broken record, but
> >> > Afghani kids won't be able to view the source of Pashto grammar
> >> > activities that don't exist, let alone interactively learn the rules
> >> > of Pashto grammar.
> >> >
> >> > Flash Ain't Open-Source
> >> >
> >> > Flash is not _as_ closed-source as other software applications like
> >> > Windows. The Adobe has published the specification for their SWF file
> >> > format and the ActionScript 3.0 compiler is open-source. However, the
> >> > Adobe's development tools such as Adobe Animator, Illustrator,
> >> > Photoshop, etc. are not open-source. Nor is Adobe's flash player
> >> > plugin. There is the open-source Gnash player but it does not fully
> >> > support Actionscript 3 or Flash version 9. Rob Savoye and his team at
> >> > Open Media Now do a great job but they seriously lack resources. Note:
> >> > Rob
> >> > Savoye, please correct my egregious errors.
> >> >
> >> > Javascript Isn't Ready
> >> >
> >> > I put in a good number of research hours into this article. I really,
> >> > really wanted to find a pure javascript framework that could compete
> >> > with Flash. I couldn't find one that does. There are libraries like
> >> > DOJO, JQuery, and Processing.js
> >> > http://ejohn.org/blog/processingjs/. Unfortunately, there aren't any
> >> > IDE's that provide WYSIWYG animation editing for these tools. Every
> >> > try to edit photos from a text editor? It's painful, really
> >> > painful. So while real programmers use emacs (or vi, joe, sam, etc.),
> >> > designers use WYSIWYG GUI's.
> >> >
> >> > Sadly, Javascript can't use the Graphics Processing Unit like Flash
> >> > can. Ouch, it's a pain in the ass to couple animations with sound
> >> > files. Based on my research so far, pure javascript won't be able to
> >> > compete with Flash for at least the next several years. Please prove
> >> > me wrong. Please post a comment to this article linking to some
> >> > Javascript wonderfulness that pulls even with Flash.
> >> >
> >> >
> >> > I will continue with the assumption that KARMA will use flash. I will
> >> > happily revise this article ex post facto if someone in cyberspace
> >> > points me to a pure javascript solution that makes activity designers
> >> > happy.
> >> >
> >> > Building Momentum for Gnash
> >> >
> >> > I believe that the best way to increase interest in fully open-source
> >> > flash is to make Flash more central in the evolving open-source
> >> > education stack rather than minimizing its role. We definitely cannot
> >> > wait for Gnash to fully support every feature of the proprietary flash
> >> > before we begin using it. Open-Source starts when a single developer
> >> > "scratches an itch" as the proverb goes. It follows then that the best
> >> > way to bring Gnash up to speed we need to create a nasty, festering
> >> > sore that irritates the open-source community into action.
> >> >
> >> > Moving the Conversation Forward
> >> >
> >> > Many people will likely hate my promotion of Flash for learning
> >> > activities. It's OK if you hate me and Flash. I do hope you recognize
> >> > that we need a more developer-centric activity framework that uses web
> >> > technologies.
> >> >
> >> > I have a lot more to write about Nepal's experiences developing
> >> > learning activities and my ideas on Convention over Configuration in
> >> > sugar activities. I will save those for another day.
> >> >
> >> >
> >> > --
> >> > Bryan W. Berry
> >> > Technology Director
> >> > OLE Nepal, http://www.olenepal.org
> >> >
> >> > _______________________________________________
> >> > IAEP -- It's An Education Project (not a laptop project!)
> >> > IAEP at lists.sugarlabs.org
> >> > http://lists.sugarlabs.org/listinfo/iaep
> >> >
> > --
> > Bryan W. Berry
> > Technology Director
> > OLE Nepal, http://www.olenepal.org
> >
> >
--
Bryan W. Berry
Technology Director
OLE Nepal, http://www.olenepal.org
From bryan at olenepal.org Sat Jan 3 14:04:10 2009
From: bryan at olenepal.org (Bryan Berry)
Date: Sat, 03 Jan 2009 11:04:10 -0800
Subject: [Sugar-devel] Education on the XO
In-Reply-To: <495F5AB6.2060806@usa.net>
References: <495F5AB6.2060806@usa.net>
Message-ID: <1231009450.32208.70.camel@hitman>
On Sat, 2009-01-03 at 07:31 -0500, Tony Anderson wrote:
> The XO's primary tool for education, as opposed to learning experiences,
> is Moodle. The problem is that Moodle for the XO is a tool which is
> ready and waiting to be used (all dressed up and no where to go).
Thanks for bringing this up Tony. I didn't properly address moodle in my
very long article about Karma, a new activity framework for Sugar.
Whatever karma or the default activity framework Sugar become, a key
element will be easy integration with moodle.
--
Bryan W. Berry
Technology Director
OLE Nepal, http://www.olenepal.org
From sascha-ml-ui-sugar-devel at silbe.org Sun Jan 4 08:37:05 2009
From: sascha-ml-ui-sugar-devel at silbe.org (Sascha Silbe)
Date: Sun, 4 Jan 2009 14:37:05 +0100
Subject: [Sugar-devel] Teaching typing and basic math on the XO
In-Reply-To: <7087c32a0901021742i49aaa97rd70d2a8992e8b217@mail.gmail.com>
References: <1230912293.17108.41.camel@hitman>
<1230923827.17108.65.camel@hitman>
<7087c32a0901021154r506f1f76k8b61cb0a68b2c672@mail.gmail.com>
<1230927010.17108.103.camel@hitman>
<20090102235506.GA23251@twin.sascha.silbe.org>
<7087c32a0901021620t76f42fcele8c97ed01cedc3d8@mail.gmail.com>
<20090103003834.GB23251@twin.sascha.silbe.org>
<7087c32a0901021742i49aaa97rd70d2a8992e8b217@mail.gmail.com>
Message-ID: <20090104133705.GA11101@twin.sascha.silbe.org>
On Fri, Jan 02, 2009 at 08:42:21PM -0500, Wade Brainerd wrote:
> I'm following the format used by programs like MicroType and Mavis
> Beacon
> Teaches Typing (what I personally learned on). Both have demo
> versions for
> Windows available.
Do you know where I could find some screenshots or similar showing the
basic concept?
I don't really fancy booting Windows and downloading a 380MB (!) demo.
Otherwise...
> We are working towards an alpha in early January.. When it's ready I
> will
> announce it on the sugar list.
... I'll just wait for that one. :)
CU Sascha
--
http://sascha.silbe.org/
http://www.infra-silbe.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: Digital signature
Url : http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090104/f3ffa31e/attachment-0001.pgp
From billkerr at gmail.com Sun Jan 4 09:16:39 2009
From: billkerr at gmail.com (Bill Kerr)
Date: Mon, 5 Jan 2009 00:46:39 +1030
Subject: [Sugar-devel] [IAEP] How to Make Activity Designers Happy ,
Parts I and II
In-Reply-To: <1230927913.17108.110.camel@hitman>
References: <1230861040.17108.4.camel__8009.18864920295$1230861178$gmane$org@hitman>
<1230912293.17108.41.camel@hitman>
<1230923827.17108.65.camel@hitman>
<7087c32a0901021154r506f1f76k8b61cb0a68b2c672@mail.gmail.com>
<1230927010.17108.103.camel@hitman>
<1230927913.17108.110.camel@hitman>
Message-ID: <5d2dce520901040616u283dd3ads181121a84a30d4cd@mail.gmail.com>
On Sat, Jan 3, 2009 at 6:55 AM, Bryan Berry wrote:
> On Fri, 2009-01-02 at 15:18 -0500, Walter Bender wrote:
>
> > (3) We need lots more Activities.
>
> While there is consensus on this point, there is not consensus on the
> best way to get a lot more Activities. That is, pulling a lot more
> developers into building learning activities that run on Sugar.
I think what we need are quality activities from both a technical and
educational perspective, which is a different position from more activities
The way I read Bryan's position is that it is based on some particularities
of the Nepal situation some of which have been spelt out in the article but
some other educational conditions which were not spelt out
What has been spelt out:
- Nepal is a poor country cf Uruguay and other Latin American countries
(Purchasing Power Parity PPP$ adjusted income per person Uruguay 8,653;
Nepal 1052)
- Most Nepal teachers have not seen computers before unlike their Latin
American counterparts
- Nepal developers have existing skills in certain technologies (HTML,
CSS, Javsscript, Flash) and not in others (Python, PyGTK)
- Nepal developers are time strapped and have strong obligations to their
families
- They do have time and willingness to contribute to more activities but
that requires acceptance, understanding and incorporation of their existing
skill set into the sugar project
What was not spelt out (Bryan will correct me if I am incorrect):
- Existing Nepal curriculum is very structured
- Strong pressure on teachers and students to pass existing curriculum
because of penalties involved for failing
I can see the logic of Bryan's position when the whole spectrum of Nepal
circumstances are spelt out but I'm wondering how much these factors, some
of which are local to Nepal, should influence the whole project. How much
should Bryan's Nepal necessity - FOSS paradox be transferred to the whole
project of activity development?
Local factors - such as the ability and willingness of the existing
education system to bend and adapt - will influence how the project develops
in different countries.
I'll write another comment which addresses the issues raised about
foundational skills and constructivism (by Bryan, Walter, Wade)
The main point I'm trying to make in this comment is that there may well be
a difference between the current Nepal necessity of developing more
activities due to all the factors above (local issues) and what I see as the
general need for quality activities. I don't see processes or much
discussion for quality control from an educational perspective in place.
Making activity developers happy is not the same thing as making all
educators happy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090105/d33e93ba/attachment.htm
From tomeu at sugarlabs.org Sun Jan 4 09:32:00 2009
From: tomeu at sugarlabs.org (Tomeu Vizoso)
Date: Sun, 4 Jan 2009 15:32:00 +0100
Subject: [Sugar-devel] [IAEP] How to Make Activity Designers Happy ,
Parts I and II
In-Reply-To: <5d2dce520901040616u283dd3ads181121a84a30d4cd@mail.gmail.com>
References: <1230861040.17108.4.camel__8009.18864920295$1230861178$gmane$org@hitman>
<1230912293.17108.41.camel@hitman>
<1230923827.17108.65.camel@hitman>
<7087c32a0901021154r506f1f76k8b61cb0a68b2c672@mail.gmail.com>
<1230927010.17108.103.camel@hitman>
<1230927913.17108.110.camel@hitman>
<5d2dce520901040616u283dd3ads181121a84a30d4cd@mail.gmail.com>
Message-ID: <242851610901040632h2fff0572g56da8b06cec7fbd4@mail.gmail.com>
On Sun, Jan 4, 2009 at 15:16, Bill Kerr wrote:
> On Sat, Jan 3, 2009 at 6:55 AM, Bryan Berry wrote:
>>
>> On Fri, 2009-01-02 at 15:18 -0500, Walter Bender wrote:
>>
>> > (3) We need lots more Activities.
>>
>> While there is consensus on this point, there is not consensus on the
>> best way to get a lot more Activities. That is, pulling a lot more
>> developers into building learning activities that run on Sugar.
>
> I think what we need are quality activities from both a technical and
> educational perspective, which is a different position from more activities
>
> The way I read Bryan's position is that it is based on some particularities
> of the Nepal situation some of which have been spelt out in the article but
> some other educational conditions which were not spelt out
>
> What has been spelt out:
>
> Nepal is a poor country cf Uruguay and other Latin American countries
> (Purchasing Power Parity PPP$ adjusted income per person Uruguay 8,653;
> Nepal 1052)
> Most Nepal teachers have not seen computers before unlike their Latin
> American counterparts
> Nepal developers have existing skills in certain technologies (HTML, CSS,
> Javsscript, Flash) and not in others (Python, PyGTK)
> Nepal developers are time strapped and have strong obligations to their
> families
> They do have time and willingness to contribute to more activities but that
> requires acceptance, understanding and incorporation of their existing
> skill set into the sugar project
>
> What was not spelt out (Bryan will correct me if I am incorrect):
>
> Existing Nepal curriculum is very structured
> Strong pressure on teachers and students to pass existing curriculum because
> of penalties involved for failing
>
> I can see the logic of Bryan's position when the whole spectrum of Nepal
> circumstances are spelt out but I'm wondering how much these factors, some
> of which are local to Nepal, should influence the whole project. How much
> should Bryan's Nepal necessity - FOSS paradox be transferred to the whole
> project of activity development?
Well, I see the changes requested by Bryan as additive, so potentially
not causing any harm to other users of Sugar. Of course, for OLPC
Nepal would make more sense if their work on top of Sugar is used by
others, so the burden of maintaining it would be shared.
Also, by discussing it with the community first, other users of Sugar
can detect areas where it would be worth joining forces, thus
decreasing the burden of initial development.
Regards,
Tomeu
> Local factors - such as the ability and willingness of the existing
> education system to bend and adapt - will influence how the project develops
> in different countries.
>
> I'll write another comment which addresses the issues raised about
> foundational skills and constructivism (by Bryan, Walter, Wade)
>
> The main point I'm trying to make in this comment is that there may well be
> a difference between the current Nepal necessity of developing more
> activities due to all the factors above (local issues) and what I see as the
> general need for quality activities. I don't see processes or much
> discussion for quality control from an educational perspective in place.
> Making activity developers happy is not the same thing as making all
> educators happy.
>
>
>
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
From wadetb at gmail.com Sun Jan 4 10:23:57 2009
From: wadetb at gmail.com (Wade Brainerd)
Date: Sun, 4 Jan 2009 10:23:57 -0500
Subject: [Sugar-devel] Teaching typing and basic math on the XO
In-Reply-To: <20090104133705.GA11101@twin.sascha.silbe.org>
References: <1230912293.17108.41.camel@hitman>
<1230923827.17108.65.camel@hitman>
<7087c32a0901021154r506f1f76k8b61cb0a68b2c672@mail.gmail.com>
<1230927010.17108.103.camel@hitman>
<20090102235506.GA23251@twin.sascha.silbe.org>
<7087c32a0901021620t76f42fcele8c97ed01cedc3d8@mail.gmail.com>
<20090103003834.GB23251@twin.sascha.silbe.org>
<7087c32a0901021742i49aaa97rd70d2a8992e8b217@mail.gmail.com>
<20090104133705.GA11101@twin.sascha.silbe.org>
Message-ID: <7087c32a0901040723h64661cd5pacaf43d7f9f60259@mail.gmail.com>
I know Mavis has a simplified flash version on their website.
On Sun, Jan 4, 2009 at 8:37 AM, Sascha Silbe <
sascha-ml-ui-sugar-devel at silbe.org> wrote:
> On Fri, Jan 02, 2009 at 08:42:21PM -0500, Wade Brainerd wrote:
>
> I'm following the format used by programs like MicroType and Mavis Beacon
>> Teaches Typing (what I personally learned on). Both have demo versions
>> for
>> Windows available.
>>
> Do you know where I could find some screenshots or similar showing the
> basic concept?
> I don't really fancy booting Windows and downloading a 380MB (!) demo.
> Otherwise...
>
> We are working towards an alpha in early January.. When it's ready I will
>> announce it on the sugar list.
>>
> ... I'll just wait for that one. :)
>
>
> CU Sascha
>
> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iQEVAwUBSWC7gbpz82VMF3DaAQIthAf9FYjDR/jthfsnaQnZV5pLifKTrQxWGzY8
> LQBrGPZQRa2D2+0jnvmiSCqsxKZXIuZArUbJP2pt7RSJ+T2w6UygZkbu81SStMmX
> AyOtTpKHjQniJzz15rozw23hXVTP1Qo2gncZambMgG123jb2q1D79GUPZL1yczFP
> sxrvW+13tlQq8PjUwuTnZiD8h3EG9wlQpGXWJuBXtNiqg2g1M7B8fO12dMkeTrBg
> VLt9Y8jBgMY50ecvg7qpSDK9fn1fF78TPGEljEiPlf7AslDK3p7/4BplfwZKwGDh
> zhT69cCub/fY01CJ5aUFe5xav9/WJiWD8rLU2pU5PZXI/FJuZLNOeg==
> =AKsd
> -----END PGP SIGNATURE-----
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090104/b85b669b/attachment.htm
From sascha-ml-ui-sugar-devel at silbe.org Sun Jan 4 11:26:17 2009
From: sascha-ml-ui-sugar-devel at silbe.org (Sascha Silbe)
Date: Sun, 4 Jan 2009 17:26:17 +0100
Subject: [Sugar-devel] Teaching typing and basic math on the XO
In-Reply-To: <7087c32a0901040723h64661cd5pacaf43d7f9f60259@mail.gmail.com>
References: <1230923827.17108.65.camel@hitman>
<7087c32a0901021154r506f1f76k8b61cb0a68b2c672@mail.gmail.com>
<1230927010.17108.103.camel@hitman>
<20090102235506.GA23251@twin.sascha.silbe.org>
<7087c32a0901021620t76f42fcele8c97ed01cedc3d8@mail.gmail.com>
<20090103003834.GB23251@twin.sascha.silbe.org>
<7087c32a0901021742i49aaa97rd70d2a8992e8b217@mail.gmail.com>
<20090104133705.GA11101@twin.sascha.silbe.org>
<7087c32a0901040723h64661cd5pacaf43d7f9f60259@mail.gmail.com>
Message-ID: <20090104162617.GB11101@twin.sascha.silbe.org>
On Sun, Jan 04, 2009 at 10:23:57AM -0500, Wade Brainerd wrote:
> I know Mavis has a simplified flash version on their website.
Got a URL? Cannot find it, even after half an hour of searching the web
(most hits are online software stores).
The screenshots I found suggest at least the included "typing games" are
similar to TuxType (haven't found ones showing anything else).
CU Sascha
--
http://sascha.silbe.org/
http://www.infra-silbe.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: Digital signature
Url : http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090104/11f136a4/attachment.pgp
From wadetb at gmail.com Sun Jan 4 12:11:07 2009
From: wadetb at gmail.com (Wade Brainerd)
Date: Sun, 4 Jan 2009 12:11:07 -0500
Subject: [Sugar-devel] Teaching typing and basic math on the XO
In-Reply-To: <20090104162617.GB11101@twin.sascha.silbe.org>
References: <1230923827.17108.65.camel@hitman>
<7087c32a0901021154r506f1f76k8b61cb0a68b2c672@mail.gmail.com>
<1230927010.17108.103.camel@hitman>
<20090102235506.GA23251@twin.sascha.silbe.org>
<7087c32a0901021620t76f42fcele8c97ed01cedc3d8@mail.gmail.com>
<20090103003834.GB23251@twin.sascha.silbe.org>
<7087c32a0901021742i49aaa97rd70d2a8992e8b217@mail.gmail.com>
<20090104133705.GA11101@twin.sascha.silbe.org>
<7087c32a0901040723h64661cd5pacaf43d7f9f60259@mail.gmail.com>
<20090104162617.GB11101@twin.sascha.silbe.org>
Message-ID: <7087c32a0901040911j1208950an50c169aa787f17b8@mail.gmail.com>
http://www.youtube.com/watch?v=ocBgc55sEsI
On Sun, Jan 4, 2009 at 11:26 AM, Sascha Silbe <
sascha-ml-ui-sugar-devel at silbe.org> wrote:
> On Sun, Jan 04, 2009 at 10:23:57AM -0500, Wade Brainerd wrote:
>
> I know Mavis has a simplified flash version on their website.
>>
> Got a URL? Cannot find it, even after half an hour of searching the web
> (most hits are online software stores).
> The screenshots I found suggest at least the included "typing games" are
> similar to TuxType (haven't found ones showing anything else).
>
>
> CU Sascha
>
> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iQEVAwUBSWDjKbpz82VMF3DaAQKK/Qf/fihyyFU/Ci4nESfoTOo7C4+ROjNRaEDw
> JcPXnuicA37jZEHLkYOmFvdSh2Bl9vZB38Wh5EbI5LtZXaODMJPy/yrq5lVLFrJj
> imyula2fWezNOSZHhvGl2TifCWTQo/IhL9KmtBZ2nCIX9zUFdsqdyB7ofxok/RMJ
> XgKDMXs1Ap/AKHT6S5OBR6S0npGSoz3/x2F3mCsyaDg0PtYoOzvOQLlb+rtOIwBv
> IMWvhjR2XumUT0/yZtI4URZgroTLh4wfy8v5PF5J1TobMpDp9ozYQsxoPUh2wJa8
> XJ1uJyU5V4BMhRVcFmZUs2G6437jFthhEuLNMrtkq18mUpsC+4qiig==
> =hiYJ
> -----END PGP SIGNATURE-----
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090104/6a5f5566/attachment.htm
From dvanassche at gmail.com Sun Jan 4 16:32:16 2009
From: dvanassche at gmail.com (David Van Assche)
Date: Sun, 4 Jan 2009 22:32:16 +0100
Subject: [Sugar-devel] [IAEP] Education on the XO
In-Reply-To: <1231009450.32208.70.camel@hitman>
References: <495F5AB6.2060806@usa.net> <1231009450.32208.70.camel@hitman>
Message-ID: <8cc423ef0901041332s32439b1dycb28e4ca9f15c0b4@mail.gmail.com>
Actually there are a whole bunch of examples I uploaded to
schools.sugarlabs.org, the problem we have is of how to categorise
them. ie... do we put them via subject, via class, via country, via
language?
The infrastructure needs to be discussed and then agreed upon. That's
the main reason why I didn't upload anything else. That and I realised
I'm the only one adding anything to the site ;-) That said, the entire
Open University content is creative commons, and can be easily
ported.... and there are many sources across the internet that offer
moodle material in various languages. I pasted a list of the best
curriculum and learning sources on schools.sugarlabs.org. There are
enough examples up there for course creators to get an idea of how to
create an effective learning course, and even some usable courses
(intro to gimp, intro to networking, etc.) Moodle is really quite
simple to get the hang off, but like everything else, it requires
putting time into it. If there are any course content creators out
there, I'd love to hear their ideas, and if they need help with
creating courses on the schools.sugarlabs.org site, I believe I can
help.
I also began creating a database of all the activities so that they
can easily be searched for, categorised, etc. but I read that this was
being done elsewhere so again, I didn't continue down that avenue, but
I'll gladly continue if its of use...
kind Regards,
David Van Assche
On Sat, Jan 3, 2009 at 8:04 PM, Bryan Berry wrote:
> On Sat, 2009-01-03 at 07:31 -0500, Tony Anderson wrote:
>> The XO's primary tool for education, as opposed to learning experiences,
>> is Moodle. The problem is that Moodle for the XO is a tool which is
>> ready and waiting to be used (all dressed up and no where to go).
>
> Thanks for bringing this up Tony. I didn't properly address moodle in my
> very long article about Karma, a new activity framework for Sugar.
> Whatever karma or the default activity framework Sugar become, a key
> element will be easy integration with moodle.
>
>
> --
> Bryan W. Berry
> Technology Director
> OLE Nepal, http://www.olenepal.org
>
> _______________________________________________
> IAEP -- It's An Education Project (not a laptop project!)
> IAEP at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>
From michael at laptop.org Sun Jan 4 17:55:39 2009
From: michael at laptop.org (Michael Stone)
Date: Sun, 4 Jan 2009 17:55:39 -0500
Subject: [Sugar-devel] anonymous gray activity circles
In-Reply-To: <495FBB3D.5080800@comcast.net>
References: <495B7F96.7060308@usa.net> <495FBB3D.5080800@comcast.net>
Message-ID: <20090104225539.GL3164@didacte.laptop.org>
On Sat, Jan 03, 2009 at 02:23:41PM -0500, Chris Marshall wrote:
>Two specific questions come to mind:
>
>(1) How does Sugar know that a new top level
> window has been instantiated? Is there a
> hook from the X server or what?
Here's a short code tour for your enjoyment. I'll start by tracing
backwards from what we know:
1. Clone the sugar source code:
git clone git://git.sugarlabs.org/sugar/mainline.git sugar
2. We know that things including gray circles appear in the top part of
the frame. What causes this?
cd sugar
find . -name '*frame*'
# Inspiration!
cd src/jarabe/frame
3. Start reading files here looking for info about how the frame is
constructed.
Ah hah! We find out from src/jarabe/frame/frame.py that the frame
consists of four panels.
http://git.sugarlabs.org/projects/sugar/repos/mainline/blobs/master/src/jarabe/frame/frame.py#line117
What goes in the top panel? Read _create_top_panel():
http://git.sugarlabs.org/projects/sugar/repos/mainline/blobs/master/src/jarabe/frame/frame.py#line177
Bingo! An ActivitiesTray()!
4. Go find ActivitiesTray():
First, search for "ActivitiesTray". Find the import line at
http://git.sugarlabs.org/projects/sugar/repos/mainline/blobs/master/src/jarabe/frame/frame.py#line29
Next, go read src/jarabe/frame/activitiestray.py looking for the
definition of ActivitiesTray()
http://git.sugarlabs.org/projects/sugar/repos/mainline/blobs/master/src/jarabe/frame/activitiestray.py#line299
5. Figure out what message causes the tray to add icons.
Doesn't that __activity_added_cb() callback look suspicious?
Let's figure out what causes self._home_model to generate
'activity-added' signals.
6. Track down self._home_model.
Ah! In ActivitiesTray.__init__, we set it equal to shell.get_model().
Where does the variable "shell" come from? From here:
http://git.sugarlabs.org/projects/sugar/repos/mainline/blobs/master/src/jarabe/frame/activitiestray.py#line39
7. Track down 'get_model' in src/jarabe/model/shell.py
http://git.sugarlabs.org/projects/sugar/repos/mainline/blobs/master/src/jarabe/model/shell.py#line573
So what's a ShellModel?
8. Look more carefully at ShellModel.
We find the definition of the 'activity-added' signal here:
http://git.sugarlabs.org/projects/sugar/repos/mainline/blobs/master/src/jarabe/model/shell.py#line282
alongside several other tasty-sounding signals.
...
Oooh, look at the __init__ method:
http://git.sugarlabs.org/projects/sugar/repos/mainline/blobs/master/src/jarabe/model/shell.py#line310
Doesn't that "window-open" signal sound interesting?
9. Review.
We've pretty much figured out the chain of events that results in the
appearance of a new button on the frame's top panel's activities tray.
Moreover, while we still don't really know why the buttons sometimes
display gray circles vs activity icons or how to remove a button, we
can be fairly sure that the answers lie close by, e.g.
(where the gray circles come from:)
http://git.sugarlabs.org/projects/sugar/repos/mainline/blobs/master/src/jarabe/frame/activitiestray.py#line67
and back in jarabe.model.shell.ShellModel, which seems to be driving
the show w.r.t. to the display and removal of items in the
ActivitiesTray.
10. Forward.
The questions which remain include:
a) What things are driving the ShellModel? Are they doing so
correctly?
hint: nope. read
http://git.sugarlabs.org/projects/sugar/repos/mainline/blobs/master/src/jarabe/model/shell.py#line434
http://standards.freedesktop.org/startup-notification-spec/startup-notification-latest.txt
(also, please help me get the ideas in the patches at the top of
http://dev.laptop.org/git/users/mstone/sugar and
http://dev.laptop.org/git/users/mstone/sugar-toolkit
merged which, while they won't solve your problem, may still be
generally useful.)
b) What icon data should we be feeding into those buttons? Where
does it come from?
hint: read
http://standards.freedesktop.org/wm-spec/latest/
http://standards.freedesktop.org/wm-spec/latest/ar01s05.html#id2569669
and start asking questions.
Hope this helps,
Michael
From mikus at bga.com Sun Jan 4 20:15:54 2009
From: mikus at bga.com (Mikus Grinbergs)
Date: Sun, 04 Jan 2009 20:15:54 -0500
Subject: [Sugar-devel] anonymous gray activity circles
Message-ID: <49615F4A.5010104@bga.com>
> Here's a short code tour for your enjoyment.
Thank you very much, Michael. This is very helpful.
Would it be possible for you (or someone else) to similarly
enumerate the conditions under which 'anonymous gray activity
circles' are made to disappear ?
I don't have difficulty with gray circles while activities are
running (I can figure out which circle is which session) -- but it
leaves an untidy impression when the session itself goes away, but
the gray circle does not. [In fact, I once saw so many leftover
gray circles that the top bar of Frame showed "arrowheads" for the
viewer to scroll back and forth within the "ActivitiesTray".]
Maybe if I can understand *why* gray circles might persist, I might
be able to think of a way to force leftover useless ones to go away.
[I would guess a gray circle left behind by a session
could only be gotten rid of by restarting Sugar.]
mikus
From dfarning at sugarlabs.org Sun Jan 4 20:38:51 2009
From: dfarning at sugarlabs.org (David Farning)
Date: Mon, 5 Jan 2009 19:38:51 +1800
Subject: [Sugar-devel] Flash at Sugar Labs
Message-ID:
Bryan Berry started a great thread about activity development a few
days ago. In the initial post he proposed using flash as means of
developing content. Before taking the thread any farther I though we
should stop and look at what flash actually is.
The term flash is often interchangeably used as:
1. A brand
2. A player
3. A development environment
4. A protocol
Yep, confusing. As we continue the discussion, I thought we should
look at how 'flash' relates to Sugar and to more generally to OLPC and
Open Source. I have CCed MaryBeth from Open Media Now and Rob from
Gnash to help clarify the many shortcomings in my explanations.
First, the brand -
Flash is primarily a brand. It was originally created by MacroMedia
and has been purchased by Adobe. The brand consists of the player,
IDE, protocol, and the support and marketing provided by Adobe. As a
brand, Flash is competing head-to-head with Microsoft's Silverlight.
Second, the player -
The most visible part of flash is the player. The _Adobe_Flash_Player
is a proprietary product which is developed, supported, and
distributed by Adobe. Currently, the Adobe Flash Player can only be
distributed with Adobe's permission. Binary code for the player can
be downloaded for most operating systems and distributions.
Third party redistribution is strictly prohibited without permission.
As such it would not be possible for Sugar Labs to distribute the
Adobe_Flash_Player in its code bundles. Deployments can, and often
do, add the Player as an available activity. The Player can be
legally redistributed over an organization's intra-net.
Third, the authoring tools -
Adobe's business model is to give away the player and sell the
authoring tools. As a result, Adobe sells several very good, yet,
expensive authoring tools. Adobe's development tool costs
approximately $750 US.
Fourth, the Standards -
Flash deliverables come in two formats .swf and .flv. Swf and
ActionScript, the development language use to create .swfs have been
open sourced. I believe that the ActionScript source code is jointly
held by Adobe and Mozilla. There are possible legal questions about
the patent encumberment status of some of the media codecs used in
swfs and flvs. We would need clarification from the Software Freedom
Conservancy on these issues.
So, counting backwards how does this affect Sugar Lab?
Fourth, the Standards -
We need to wait for feedback from the SFC and Open Media Now.
Third, the authoring tools -
Adobe has done a very effective job eliminating the competition for
flash authoring tools. http://osflash.org/ has a number of open
source development tools. I am not enough of a flash developer to
judge if the authoring products are mature enough to be useful or not.
Are there any Flash developers out there, can you judge the quality
of some of these products?
Second, the player -
The Free Software Foundation has flash player project called Gnash.
The project is makin slow yet steady progress towards being a fully
capable swf player. The project suffers from lack of support. Many
Open Source users either download the Adobe player or forgo using
flash. The itch factor is pretty low.
As a product, Gnash is approaching, yet is not yet ready for, prime
time. I spent New Years Day with my sister's kids( ages 11, 7, and 4)
looking at their favorites sites under Ubuntu/Flash, Ubuntu/Gnash,
Xo/Flash, and Xo,Flash. I bet that was the first time they have ever
heard a adult tell them to, 'come on, play it again, just one more
time, please...' about their favorite games:)
There was a steady decrease in the availability and usability of sites
with Xo and Gnash. We need to wait for feedback from Gnash about the
product's technical limitations and the project's development
limitations.
Finally, the brand -
Adobe has recently asked Gnash to call their player a SWF player
rather than a flash player:)
I appreciate your feedback on the technical aspect of Bryan's propose.
In the next few days, I will try to summarize the (1)
organization/development and (2) the educational/pedagogically issues
of his proposal.
thanks
david
From wadetb at gmail.com Sun Jan 4 21:23:44 2009
From: wadetb at gmail.com (Wade Brainerd)
Date: Sun, 4 Jan 2009 21:23:44 -0500
Subject: [Sugar-devel] [IAEP] Flash at Sugar Labs
In-Reply-To:
References:
Message-ID: <7087c32a0901041823i3ad3deb4q3b274d4f6edf29ab@mail.gmail.com>
Personally, I don't believe that Sugar Labs the organization needs to be
concerned with any of these four points.
The question is whether the Sugar *software* is flexible enough to adapt to
the needs of its users. Who are we to say what they should install, and
what tools they should use to make their content?
Currently Sugar is incapable of running software which is not specifically
designed for it. This precludes smaller organizations who cannot design
custom Sugar activities from producing good content. Once the Sugar
software is more flexible and able to run arbitrary programs (Gnash, Flash,
Silverlight, GTK, Qt) without massive time investment and hacking on the
part of the content producers, the other questions won't even reach this
list.
Best regards,
Wade
On Sun, Jan 4, 2009 at 8:38 PM, David Farning wrote:
> Bryan Berry started a great thread about activity development a few
> days ago. In the initial post he proposed using flash as means of
> developing content. Before taking the thread any farther I though we
> should stop and look at what flash actually is.
>
> The term flash is often interchangeably used as:
> 1. A brand
> 2. A player
> 3. A development environment
> 4. A protocol
>
> Yep, confusing. As we continue the discussion, I thought we should
> look at how 'flash' relates to Sugar and to more generally to OLPC and
> Open Source. I have CCed MaryBeth from Open Media Now and Rob from
> Gnash to help clarify the many shortcomings in my explanations.
>
> First, the brand -
> Flash is primarily a brand. It was originally created by MacroMedia
> and has been purchased by Adobe. The brand consists of the player,
> IDE, protocol, and the support and marketing provided by Adobe. As a
> brand, Flash is competing head-to-head with Microsoft's Silverlight.
>
> Second, the player -
> The most visible part of flash is the player. The _Adobe_Flash_Player
> is a proprietary product which is developed, supported, and
> distributed by Adobe. Currently, the Adobe Flash Player can only be
> distributed with Adobe's permission. Binary code for the player can
> be downloaded for most operating systems and distributions.
>
> Third party redistribution is strictly prohibited without permission.
> As such it would not be possible for Sugar Labs to distribute the
> Adobe_Flash_Player in its code bundles. Deployments can, and often
> do, add the Player as an available activity. The Player can be
> legally redistributed over an organization's intra-net.
>
> Third, the authoring tools -
> Adobe's business model is to give away the player and sell the
> authoring tools. As a result, Adobe sells several very good, yet,
> expensive authoring tools. Adobe's development tool costs
> approximately $750 US.
>
> Fourth, the Standards -
> Flash deliverables come in two formats .swf and .flv. Swf and
> ActionScript, the development language use to create .swfs have been
> open sourced. I believe that the ActionScript source code is jointly
> held by Adobe and Mozilla. There are possible legal questions about
> the patent encumberment status of some of the media codecs used in
> swfs and flvs. We would need clarification from the Software Freedom
> Conservancy on these issues.
>
> So, counting backwards how does this affect Sugar Lab?
> Fourth, the Standards -
> We need to wait for feedback from the SFC and Open Media Now.
>
> Third, the authoring tools -
> Adobe has done a very effective job eliminating the competition for
> flash authoring tools. http://osflash.org/ has a number of open
> source development tools. I am not enough of a flash developer to
> judge if the authoring products are mature enough to be useful or not.
> Are there any Flash developers out there, can you judge the quality
> of some of these products?
>
> Second, the player -
> The Free Software Foundation has flash player project called Gnash.
> The project is makin slow yet steady progress towards being a fully
> capable swf player. The project suffers from lack of support. Many
> Open Source users either download the Adobe player or forgo using
> flash. The itch factor is pretty low.
>
> As a product, Gnash is approaching, yet is not yet ready for, prime
> time. I spent New Years Day with my sister's kids( ages 11, 7, and 4)
> looking at their favorites sites under Ubuntu/Flash, Ubuntu/Gnash,
> Xo/Flash, and Xo,Flash. I bet that was the first time they have ever
> heard a adult tell them to, 'come on, play it again, just one more
> time, please...' about their favorite games:)
>
> There was a steady decrease in the availability and usability of sites
> with Xo and Gnash. We need to wait for feedback from Gnash about the
> product's technical limitations and the project's development
> limitations.
>
> Finally, the brand -
> Adobe has recently asked Gnash to call their player a SWF player
> rather than a flash player:)
>
> I appreciate your feedback on the technical aspect of Bryan's propose.
> In the next few days, I will try to summarize the (1)
> organization/development and (2) the educational/pedagogically issues
> of his proposal.
>
> thanks
> david
> _______________________________________________
> IAEP -- It's An Education Project (not a laptop project!)
> IAEP at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090104/c347302b/attachment-0001.htm
From wadetb at gmail.com Sun Jan 4 21:28:34 2009
From: wadetb at gmail.com (Wade Brainerd)
Date: Sun, 4 Jan 2009 21:28:34 -0500
Subject: [Sugar-devel] [IAEP] Flash at Sugar Labs
In-Reply-To: <7087c32a0901041823i3ad3deb4q3b274d4f6edf29ab@mail.gmail.com>
References:
<7087c32a0901041823i3ad3deb4q3b274d4f6edf29ab@mail.gmail.com>
Message-ID: <7087c32a0901041828p1af5dc63u2280a09c3b4ee1cd@mail.gmail.com>
I should add one assumption that I'm making, which is that Flash will never
be considered the *primary* content authoring solution for Sugar activities.
If it were to become so, given the current state as outlined by David's 4
points, there needs to be significant support by Sugar Labs for the Flash
development tools, financially and with code. But from my perspective, the
challenges associated with making it a primary content authoring system are
so large as to be not worth pursuing when a few simple tweaks to the current
software stack would get you 90% of the way there.
Cheers,
-Wade
On Sun, Jan 4, 2009 at 9:23 PM, Wade Brainerd wrote:
> Personally, I don't believe that Sugar Labs the organization needs to be
> concerned with any of these four points.
>
> The question is whether the Sugar *software* is flexible enough to adapt to
> the needs of its users. Who are we to say what they should install, and
> what tools they should use to make their content?
>
> Currently Sugar is incapable of running software which is not specifically
> designed for it. This precludes smaller organizations who cannot design
> custom Sugar activities from producing good content. Once the Sugar
> software is more flexible and able to run arbitrary programs (Gnash, Flash,
> Silverlight, GTK, Qt) without massive time investment and hacking on the
> part of the content producers, the other questions won't even reach this
> list.
>
> Best regards,
> Wade
>
> On Sun, Jan 4, 2009 at 8:38 PM, David Farning wrote:
>
>> Bryan Berry started a great thread about activity development a few
>> days ago. In the initial post he proposed using flash as means of
>> developing content. Before taking the thread any farther I though we
>> should stop and look at what flash actually is.
>>
>> The term flash is often interchangeably used as:
>> 1. A brand
>> 2. A player
>> 3. A development environment
>> 4. A protocol
>>
>> Yep, confusing. As we continue the discussion, I thought we should
>> look at how 'flash' relates to Sugar and to more generally to OLPC and
>> Open Source. I have CCed MaryBeth from Open Media Now and Rob from
>> Gnash to help clarify the many shortcomings in my explanations.
>>
>> First, the brand -
>> Flash is primarily a brand. It was originally created by MacroMedia
>> and has been purchased by Adobe. The brand consists of the player,
>> IDE, protocol, and the support and marketing provided by Adobe. As a
>> brand, Flash is competing head-to-head with Microsoft's Silverlight.
>>
>> Second, the player -
>> The most visible part of flash is the player. The _Adobe_Flash_Player
>> is a proprietary product which is developed, supported, and
>> distributed by Adobe. Currently, the Adobe Flash Player can only be
>> distributed with Adobe's permission. Binary code for the player can
>> be downloaded for most operating systems and distributions.
>>
>> Third party redistribution is strictly prohibited without permission.
>> As such it would not be possible for Sugar Labs to distribute the
>> Adobe_Flash_Player in its code bundles. Deployments can, and often
>> do, add the Player as an available activity. The Player can be
>> legally redistributed over an organization's intra-net.
>>
>> Third, the authoring tools -
>> Adobe's business model is to give away the player and sell the
>> authoring tools. As a result, Adobe sells several very good, yet,
>> expensive authoring tools. Adobe's development tool costs
>> approximately $750 US.
>>
>> Fourth, the Standards -
>> Flash deliverables come in two formats .swf and .flv. Swf and
>> ActionScript, the development language use to create .swfs have been
>> open sourced. I believe that the ActionScript source code is jointly
>> held by Adobe and Mozilla. There are possible legal questions about
>> the patent encumberment status of some of the media codecs used in
>> swfs and flvs. We would need clarification from the Software Freedom
>> Conservancy on these issues.
>>
>> So, counting backwards how does this affect Sugar Lab?
>> Fourth, the Standards -
>> We need to wait for feedback from the SFC and Open Media Now.
>>
>> Third, the authoring tools -
>> Adobe has done a very effective job eliminating the competition for
>> flash authoring tools. http://osflash.org/ has a number of open
>> source development tools. I am not enough of a flash developer to
>> judge if the authoring products are mature enough to be useful or not.
>> Are there any Flash developers out there, can you judge the quality
>> of some of these products?
>>
>> Second, the player -
>> The Free Software Foundation has flash player project called Gnash.
>> The project is makin slow yet steady progress towards being a fully
>> capable swf player. The project suffers from lack of support. Many
>> Open Source users either download the Adobe player or forgo using
>> flash. The itch factor is pretty low.
>>
>> As a product, Gnash is approaching, yet is not yet ready for, prime
>> time. I spent New Years Day with my sister's kids( ages 11, 7, and 4)
>> looking at their favorites sites under Ubuntu/Flash, Ubuntu/Gnash,
>> Xo/Flash, and Xo,Flash. I bet that was the first time they have ever
>> heard a adult tell them to, 'come on, play it again, just one more
>> time, please...' about their favorite games:)
>>
>> There was a steady decrease in the availability and usability of sites
>> with Xo and Gnash. We need to wait for feedback from Gnash about the
>> product's technical limitations and the project's development
>> limitations.
>>
>> Finally, the brand -
>> Adobe has recently asked Gnash to call their player a SWF player
>> rather than a flash player:)
>>
>> I appreciate your feedback on the technical aspect of Bryan's propose.
>> In the next few days, I will try to summarize the (1)
>> organization/development and (2) the educational/pedagogically issues
>> of his proposal.
>>
>> thanks
>> david
>> _______________________________________________
>> IAEP -- It's An Education Project (not a laptop project!)
>> IAEP at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/iaep
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090104/3178a83f/attachment.htm
From wadetb at gmail.com Sun Jan 4 21:30:55 2009
From: wadetb at gmail.com (Wade Brainerd)
Date: Sun, 4 Jan 2009 21:30:55 -0500
Subject: [Sugar-devel] anonymous gray activity circles
In-Reply-To: <20090104225539.GL3164@didacte.laptop.org>
References: <495B7F96.7060308@usa.net> <495FBB3D.5080800@comcast.net>
<20090104225539.GL3164@didacte.laptop.org>
Message-ID: <7087c32a0901041830j2ea4cf6fld5df39f2061bd15b@mail.gmail.com>
Hey Michael,
Did you try applying Sayamindu's patch from the previous email (and did you
see the associated screenshot)?
I'm surprised it hasn't been cleaned up and pushed by the Sugar dev team by
now.
-Wade
On Sun, Jan 4, 2009 at 5:55 PM, Michael Stone wrote:
> On Sat, Jan 03, 2009 at 02:23:41PM -0500, Chris Marshall wrote:
> >Two specific questions come to mind:
> >
> >(1) How does Sugar know that a new top level
> > window has been instantiated? Is there a
> > hook from the X server or what?
>
> Here's a short code tour for your enjoyment. I'll start by tracing
> backwards from what we know:
>
> 1. Clone the sugar source code:
>
> git clone git://git.sugarlabs.org/sugar/mainline.git sugar
>
> 2. We know that things including gray circles appear in the top part of
> the frame. What causes this?
>
> cd sugar
> find . -name '*frame*'
> # Inspiration!
> cd src/jarabe/frame
>
> 3. Start reading files here looking for info about how the frame is
> constructed.
>
> Ah hah! We find out from src/jarabe/frame/frame.py that the frame
> consists of four panels.
>
>
> http://git.sugarlabs.org/projects/sugar/repos/mainline/blobs/master/src/jarabe/frame/frame.py#line117
>
> What goes in the top panel? Read _create_top_panel():
>
>
> http://git.sugarlabs.org/projects/sugar/repos/mainline/blobs/master/src/jarabe/frame/frame.py#line177
>
> Bingo! An ActivitiesTray()!
>
> 4. Go find ActivitiesTray():
>
> First, search for "ActivitiesTray". Find the import line at
>
>
> http://git.sugarlabs.org/projects/sugar/repos/mainline/blobs/master/src/jarabe/frame/frame.py#line29
>
> Next, go read src/jarabe/frame/activitiestray.py looking for the
> definition of ActivitiesTray()
>
>
> http://git.sugarlabs.org/projects/sugar/repos/mainline/blobs/master/src/jarabe/frame/activitiestray.py#line299
>
> 5. Figure out what message causes the tray to add icons.
>
> Doesn't that __activity_added_cb() callback look suspicious?
>
> Let's figure out what causes self._home_model to generate
> 'activity-added' signals.
>
> 6. Track down self._home_model.
>
> Ah! In ActivitiesTray.__init__, we set it equal to shell.get_model().
>
> Where does the variable "shell" come from? From here:
>
>
> http://git.sugarlabs.org/projects/sugar/repos/mainline/blobs/master/src/jarabe/frame/activitiestray.py#line39
>
> 7. Track down 'get_model' in src/jarabe/model/shell.py
>
>
> http://git.sugarlabs.org/projects/sugar/repos/mainline/blobs/master/src/jarabe/model/shell.py#line573
>
> So what's a ShellModel?
>
> 8. Look more carefully at ShellModel.
>
> We find the definition of the 'activity-added' signal here:
>
>
> http://git.sugarlabs.org/projects/sugar/repos/mainline/blobs/master/src/jarabe/model/shell.py#line282
>
> alongside several other tasty-sounding signals.
>
> ...
>
> Oooh, look at the __init__ method:
>
>
> http://git.sugarlabs.org/projects/sugar/repos/mainline/blobs/master/src/jarabe/model/shell.py#line310
>
> Doesn't that "window-open" signal sound interesting?
>
> 9. Review.
>
> We've pretty much figured out the chain of events that results in the
> appearance of a new button on the frame's top panel's activities tray.
>
> Moreover, while we still don't really know why the buttons sometimes
> display gray circles vs activity icons or how to remove a button, we
> can be fairly sure that the answers lie close by, e.g.
>
> (where the gray circles come from:)
>
> http://git.sugarlabs.org/projects/sugar/repos/mainline/blobs/master/src/jarabe/frame/activitiestray.py#line67
>
> and back in jarabe.model.shell.ShellModel, which seems to be driving
> the show w.r.t. to the display and removal of items in the
> ActivitiesTray.
>
> 10. Forward.
>
> The questions which remain include:
>
> a) What things are driving the ShellModel? Are they doing so
> correctly?
>
> hint: nope. read
>
> http://git.sugarlabs.org/projects/sugar/repos/mainline/blobs/master/src/jarabe/model/shell.py#line434
>
> http://standards.freedesktop.org/startup-notification-spec/startup-notification-latest.txt
>
> (also, please help me get the ideas in the patches at the top of
> http://dev.laptop.org/git/users/mstone/sugar and
> http://dev.laptop.org/git/users/mstone/sugar-toolkit
> merged which, while they won't solve your problem, may still be
> generally useful.)
>
> b) What icon data should we be feeding into those buttons? Where
> does it come from?
>
> hint: read
> http://standards.freedesktop.org/wm-spec/latest/
>
> http://standards.freedesktop.org/wm-spec/latest/ar01s05.html#id2569669
> and start asking questions.
>
> Hope this helps,
>
> Michael
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090104/9931a39e/attachment-0001.htm
From wadetb at gmail.com Sun Jan 4 22:13:51 2009
From: wadetb at gmail.com (Wade Brainerd)
Date: Sun, 4 Jan 2009 22:13:51 -0500
Subject: [Sugar-devel] Teaching typing and basic math on the XO (was:
Re: [IAEP] How to Make Activity Designers Happy , Parts I and II)
In-Reply-To:
References: <1230861040.17108.4.camel__8009.18864920295$1230861178$gmane$org@hitman>
<1230912293.17108.41.camel@hitman>
<1230923827.17108.65.camel@hitman>
<7087c32a0901021154r506f1f76k8b61cb0a68b2c672@mail.gmail.com>
<1230927010.17108.103.camel@hitman>
<20090102235506.GA23251@twin.sascha.silbe.org>
<7087c32a0901021620t76f42fcele8c97ed01cedc3d8@mail.gmail.com>
Message-ID: <7087c32a0901041913ie9aefcbk3f9c11db3678d009@mail.gmail.com>
On Sat, Jan 3, 2009 at 1:49 AM, Edward Cherlin wrote:
> I would like to get hold of Omar Khayyam Moore's Edison Talking
> Typewriter program and rewrite it in a modern programming language. It
> ran on an IBM 360 and taught three-year-olds to read and write on a
> Selectric terminal with very little human intervention required.
>
My PyGTK port of Ben Sittler's Yay Bee See! could be adapted to mimic the
ETT.
- After the student has pressed some keys and gets used to the feedback of
seeing the letter and pictures, show a random picture and "disable" the
keyboard except for the corresponding key, just like ETT.
- Add a sound effect for each picture / letter combo, just like the ETT.
This is something Ben and I discussed which would not be hard to do. It's
mostly a matter of collecting the media.
- You could add a constructivist twist by letting the student paste in a new
picture and/or sound for each letter, perhaps from Record (see Walter's
Typing Turtle suggestion). The collection would be saved to the Journal.
Feel like dusting off your Python skills?
git://dev.laptop.org/users/wadeb/yay-bee-see
-Wade
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090104/ee7a225f/attachment.htm
From acahalan at gmail.com Sun Jan 4 23:49:22 2009
From: acahalan at gmail.com (Albert Cahalan)
Date: Sun, 4 Jan 2009 23:49:22 -0500
Subject: [Sugar-devel] [IAEP] Education on the XO
In-Reply-To: <8cc423ef0901041332s32439b1dycb28e4ca9f15c0b4@mail.gmail.com>
References: <495F5AB6.2060806@usa.net> <1231009450.32208.70.camel@hitman>
<8cc423ef0901041332s32439b1dycb28e4ca9f15c0b4@mail.gmail.com>
Message-ID: <787b0d920901042049h1fdf87d0se32923d052eb8705@mail.gmail.com>
David Van Assche writes:
> Actually there are a whole bunch of examples I uploaded
> to schools.sugarlabs.org, the problem we have is of how
> to categorise them. ie... do we put them via subject,
> via class, via country, via language?
I can't see anything there. It keeps demanding an account.
I have absolutely no desire for yet another web site account,
especially when Moodle will supposedly shove constructivist
bullshit down my throat.
Why can't I just browse?
> If there are any course content creators out there, I'd love
> to hear their ideas, and if they need help with creating courses
> on the schools.sugarlabs.org site, I believe I can help.
Perhaps we can find some way to work together.
In about 10 months I taught a kid about 10 years of normal honors
math. Along the way I saved all the worksheets that I made for him.
He's now beyond that, being well into my old college calculus textbook.
At the start he was only doing single-digit addition and subtraction.
Nope, it's not constructivist. It actually works.
I was careful to mark the worksheets that were not my own work.
I think that far less than 10% of the worksheets are thus not free
to be used in some other project. The free worksheets could be used
as the majority of practice problems for a set of free math books.
It's currently on graph paper, 10 lines to the inch. I don't have a
scanner for it, though maybe my 3016x2008 camera (should do 200 dpi)
would be workable. (really slow though -- I have hundreds of pages)
Conversion would involve dealing with plenty of line art. I'm not
likely to have much time for any of this, but it sure seems wasteful
to let the problems just gather dust. Perhaps success is more about
the teaching method and continuous effort though, in which case the
worksheets are less useful.
BTW, when faced with teachers that are missing or useless, something
closer to the Robinson Curriculum would be appropriate. Be sure to
note how the subject ordering avoids premature and ineffective study.
From bryan at olenepal.org Sun Jan 4 23:50:10 2009
From: bryan at olenepal.org (Bryan Berry)
Date: Sun, 04 Jan 2009 20:50:10 -0800
Subject: [Sugar-devel] possible additional talks for XOCamp2?
Message-ID: <1231131010.30071.14.camel@hitman>
I would like to give the following talks at XOCamp2 if there is space in
the schedule for them and others are interested. Please let me know if
you would be interested
1. Evolution of a deployment organization.
About the challenges of building a deployment team from scratch and
lesson learned along the way. Not a very technical talk.
2. Karma - Not for Hackers, for Designers
Talk about my still evolving ideas for a flash-based activity framework
called Karma
--
Bryan W. Berry
Technology Director
OLE Nepal, http://www.olenepal.org
From dvanassche at gmail.com Mon Jan 5 01:24:59 2009
From: dvanassche at gmail.com (David Van Assche)
Date: Mon, 5 Jan 2009 07:24:59 +0100
Subject: [Sugar-devel] [IAEP] Education on the XO
In-Reply-To: <787b0d920901042049h1fdf87d0se32923d052eb8705@mail.gmail.com>
References: <495F5AB6.2060806@usa.net> <1231009450.32208.70.camel@hitman>
<8cc423ef0901041332s32439b1dycb28e4ca9f15c0b4@mail.gmail.com>
<787b0d920901042049h1fdf87d0se32923d052eb8705@mail.gmail.com>
Message-ID: <8cc423ef0901042224s5a515b0fv43167119ec59abe6@mail.gmail.com>
Hi Albert,
You don't need an account, you can just log in as guest, although
its certainly advised to get an account so you can see the full
functionality of Moodle like its user detail manipulation, etc. Some
courses were set to non-guest or needed a key. I've changed them all
to be free, so just logging in as guest should allow you to browse
them all.
The worksheets sound awsome, If you want me to look at how they
could be put into moodle, take a photo of one, and send it my way,
we'll see if we can't easily vectorise it or turn into some kind of
interactive web based activity.
kind regards,
David Van Assche
On Mon, Jan 5, 2009 at 5:49 AM, Albert Cahalan wrote:
> David Van Assche writes:
>
>> Actually there are a whole bunch of examples I uploaded
>> to schools.sugarlabs.org, the problem we have is of how
>> to categorise them. ie... do we put them via subject,
>> via class, via country, via language?
>
> I can't see anything there. It keeps demanding an account.
> I have absolutely no desire for yet another web site account,
> especially when Moodle will supposedly shove constructivist
> bullshit down my throat.
>
> Why can't I just browse?
>
>> If there are any course content creators out there, I'd love
>> to hear their ideas, and if they need help with creating courses
>> on the schools.sugarlabs.org site, I believe I can help.
>
> Perhaps we can find some way to work together.
>
> In about 10 months I taught a kid about 10 years of normal honors
> math. Along the way I saved all the worksheets that I made for him.
> He's now beyond that, being well into my old college calculus textbook.
> At the start he was only doing single-digit addition and subtraction.
> Nope, it's not constructivist. It actually works.
>
> I was careful to mark the worksheets that were not my own work.
> I think that far less than 10% of the worksheets are thus not free
> to be used in some other project. The free worksheets could be used
> as the majority of practice problems for a set of free math books.
>
> It's currently on graph paper, 10 lines to the inch. I don't have a
> scanner for it, though maybe my 3016x2008 camera (should do 200 dpi)
> would be workable. (really slow though -- I have hundreds of pages)
> Conversion would involve dealing with plenty of line art. I'm not
> likely to have much time for any of this, but it sure seems wasteful
> to let the problems just gather dust. Perhaps success is more about
> the teaching method and continuous effort though, in which case the
> worksheets are less useful.
>
> BTW, when faced with teachers that are missing or useless, something
> closer to the Robinson Curriculum would be appropriate. Be sure to
> note how the subject ordering avoids premature and ineffective study.
>
From tony_anderson at usa.net Mon Jan 5 03:38:50 2009
From: tony_anderson at usa.net (Tony Anderson)
Date: Mon, 05 Jan 2009 03:38:50 -0500
Subject: [Sugar-devel] [IAEP] Education on the XO
In-Reply-To: <8cc423ef0901041332s32439b1dycb28e4ca9f15c0b4@mail.gmail.com>
References: <495F5AB6.2060806@usa.net> <1231009450.32208.70.camel@hitman>
<8cc423ef0901041332s32439b1dycb28e4ca9f15c0b4@mail.gmail.com>
Message-ID: <4961C71A.7020202@usa.net>
David,
I didn't realize that you were the source of the content on
schools.sugarlabs.org. Thanks for posting the courses. I also looked at
the database of possible sources. A good start on that.
I hope that we will have a chance to discuss the infrastructure needs
next week in Boston.
Tony
David Van Assche wrote:
> Actually there are a whole bunch of examples I uploaded to
> schools.sugarlabs.org, the problem we have is of how to categorise
> them. ie... do we put them via subject, via class, via country, via
> language?
>
> The infrastructure needs to be discussed and then agreed upon. That's
> the main reason why I didn't upload anything else. That and I realised
> I'm the only one adding anything to the site ;-) That said, the entire
> Open University content is creative commons, and can be easily
> ported.... and there are many sources across the internet that offer
> moodle material in various languages. I pasted a list of the best
> curriculum and learning sources on schools.sugarlabs.org. There are
> enough examples up there for course creators to get an idea of how to
> create an effective learning course, and even some usable courses
> (intro to gimp, intro to networking, etc.) Moodle is really quite
> simple to get the hang off, but like everything else, it requires
> putting time into it. If there are any course content creators out
> there, I'd love to hear their ideas, and if they need help with
> creating courses on the schools.sugarlabs.org site, I believe I can
> help.
>
> I also began creating a database of all the activities so that they
> can easily be searched for, categorised, etc. but I read that this was
> being done elsewhere so again, I didn't continue down that avenue, but
> I'll gladly continue if its of use...
>
> kind Regards,
> David Van Assche
>
> On Sat, Jan 3, 2009 at 8:04 PM, Bryan Berry wrote:
>> On Sat, 2009-01-03 at 07:31 -0500, Tony Anderson wrote:
>>> The XO's primary tool for education, as opposed to learning experiences,
>>> is Moodle. The problem is that Moodle for the XO is a tool which is
>>> ready and waiting to be used (all dressed up and no where to go).
>> Thanks for bringing this up Tony. I didn't properly address moodle in my
>> very long article about Karma, a new activity framework for Sugar.
>> Whatever karma or the default activity framework Sugar become, a key
>> element will be easy integration with moodle.
>>
>>
>> --
>> Bryan W. Berry
>> Technology Director
>> OLE Nepal, http://www.olenepal.org
>>
>> _______________________________________________
>> IAEP -- It's An Education Project (not a laptop project!)
>> IAEP at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/iaep
>>
>
> .
>
From dvanassche at gmail.com Mon Jan 5 04:07:43 2009
From: dvanassche at gmail.com (David Van Assche)
Date: Mon, 5 Jan 2009 10:07:43 +0100
Subject: [Sugar-devel] [IAEP] Education on the XO
In-Reply-To: <4961C71A.7020202@usa.net>
References: <495F5AB6.2060806@usa.net> <1231009450.32208.70.camel@hitman>
<8cc423ef0901041332s32439b1dycb28e4ca9f15c0b4@mail.gmail.com>
<4961C71A.7020202@usa.net>
Message-ID: <8cc423ef0901050107q6e76e6e4offfa4400fb987cf3@mail.gmail.com>
Maybe we should try and put together some sort of roadmap and strategy
for schools.sugarlabs.org. Perhaps we could schedule an IRC meeting
regarding it?
kind Regards,
David Van Assche
On Mon, Jan 5, 2009 at 9:38 AM, Tony Anderson wrote:
> David,
>
> I didn't realize that you were the source of the content on
> schools.sugarlabs.org. Thanks for posting the courses. I also looked at the
> database of possible sources. A good start on that.
>
> I hope that we will have a chance to discuss the infrastructure needs next
> week in Boston.
>
> Tony
>
>
> David Van Assche wrote:
>>
>> Actually there are a whole bunch of examples I uploaded to
>> schools.sugarlabs.org, the problem we have is of how to categorise
>> them. ie... do we put them via subject, via class, via country, via
>> language?
>>
>> The infrastructure needs to be discussed and then agreed upon. That's
>> the main reason why I didn't upload anything else. That and I realised
>> I'm the only one adding anything to the site ;-) That said, the entire
>> Open University content is creative commons, and can be easily
>> ported.... and there are many sources across the internet that offer
>> moodle material in various languages. I pasted a list of the best
>> curriculum and learning sources on schools.sugarlabs.org. There are
>> enough examples up there for course creators to get an idea of how to
>> create an effective learning course, and even some usable courses
>> (intro to gimp, intro to networking, etc.) Moodle is really quite
>> simple to get the hang off, but like everything else, it requires
>> putting time into it. If there are any course content creators out
>> there, I'd love to hear their ideas, and if they need help with
>> creating courses on the schools.sugarlabs.org site, I believe I can
>> help.
>>
>> I also began creating a database of all the activities so that they
>> can easily be searched for, categorised, etc. but I read that this was
>> being done elsewhere so again, I didn't continue down that avenue, but
>> I'll gladly continue if its of use...
>>
>> kind Regards,
>> David Van Assche
>>
>> On Sat, Jan 3, 2009 at 8:04 PM, Bryan Berry wrote:
>>>
>>> On Sat, 2009-01-03 at 07:31 -0500, Tony Anderson wrote:
>>>>
>>>> The XO's primary tool for education, as opposed to learning experiences,
>>>> is Moodle. The problem is that Moodle for the XO is a tool which is
>>>> ready and waiting to be used (all dressed up and no where to go).
>>>
>>> Thanks for bringing this up Tony. I didn't properly address moodle in my
>>> very long article about Karma, a new activity framework for Sugar.
>>> Whatever karma or the default activity framework Sugar become, a key
>>> element will be easy integration with moodle.
>>>
>>>
>>> --
>>> Bryan W. Berry
>>> Technology Director
>>> OLE Nepal, http://www.olenepal.org
>>>
>>> _______________________________________________
>>> IAEP -- It's An Education Project (not a laptop project!)
>>> IAEP at lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/iaep
>>>
>>
>> .
>>
>
>
>
From bert at freudenbergs.de Mon Jan 5 07:15:28 2009
From: bert at freudenbergs.de (Bert Freudenberg)
Date: Mon, 5 Jan 2009 13:15:28 +0100
Subject: [Sugar-devel] [IAEP] Flash at Sugar Labs
In-Reply-To:
References:
<7087c32a0901041823i3ad3deb4q3b274d4f6edf29ab@mail.gmail.com>
Message-ID: <659C6A9C-6780-4373-8148-2A24F84E95AF@freudenbergs.de>
On 05.01.2009, at 05:24, John Watlington wrote:
> On Jan 4, 2009, at 9:23 PM, Wade Brainerd wrote:
>> Currently Sugar is incapable of running software which is not
>> specifically designed for it.
> Sugar runs simpler SWF applications just fine, through the Browser.
> They don't have to be "designed" for Sugar.
I think this goes besides the original point of Bryan. He is well
aware that software needs to be specifically designed for Sugar, and
wether this is good or bad is not the current debate. The point is
what tools one can use to implement a proper Sugar activity. Bryan
says the tools many content developers are familiar with are HTML,
Javascript, and Flash.
So how could an activity look like that can be authored primarily
using Adobe's Flash tools?
I think it would be relatively easy to come up with an activity
template that just has a subdirectory for SWF content. Creating an SWF
activity then would involve copying the template, editing the meta
data, putting the SWF content into the directory, zipping it up and
voila, a nice XO bundle. That process could easily be done by a
script, even on Windows.
IMHO that activity should be a wrapper for Gnash, perhaps as a native
GTK+ application, without the browser baggage (maybe such a stand-
alone player does exist already?). Since the content is authored
specifically for Sugar (and in Nepal's case even more specifically for
Sugar on the OLPC XO-1) it can easily be tuned to work well in Gnash.
Hopefully Gnash's current limitations are well documented so authors
can avoid pitfalls. That "sugarized SWF player" could even be extended
to integrate nicely with the Journal (being able to do that is the
point of having a free implementation after all) - there is no need to
be compatible with Adobe's Flash player.
My 1/50 ? ...
- Bert -
From wadetb at gmail.com Mon Jan 5 09:12:43 2009
From: wadetb at gmail.com (Wade Brainerd)
Date: Mon, 5 Jan 2009 09:12:43 -0500
Subject: [Sugar-devel] [IAEP] Flash at Sugar Labs
In-Reply-To:
References:
<7087c32a0901041823i3ad3deb4q3b274d4f6edf29ab@mail.gmail.com>
Message-ID: <7087c32a0901050612l791de3cfg6773ee4d9c5e4ce6@mail.gmail.com>
On Sun, Jan 4, 2009 at 11:24 PM, John Watlington wrote:
> On Jan 4, 2009, at 9:23 PM, Wade Brainerd wrote:
>> Personally, I don't believe that Sugar Labs the organization needs to be concerned with any of these four points.
>
> Ahh, but a recurring question from existing Sugar deployments is how to get Flash, why Flash doesn't run faster, etc.
This appears to contradict the following statement.
>> Currently Sugar is incapable of running software which is not specifically designed for it.
>
> Sugar runs simpler SWF applications just fine, through the Browser. They don't have to be
> "designed" for Sugar.
This thread isn't about simpler SWF files (punch the monkey, etc).
It's about learning activities written in Flash. OTOH, if web games
etc get better as a result, great.
>> The question is whether the Sugar *software* is flexible enough to adapt to the needs of its users. Who are we to say what they should install, and what tools they should use to make their content?
>
>The question is what answer you provide to this crucial question.
It's not my question to answer, nor Sugar Labs. It's a good idea to
support other OSS software, but not when it runs counter to the
mission of the project. Macromedia created, supported and marketed
Flash. They deserve to make some money from it. Gnash will be a
wonderful solution when it's ready for prime time. But it's up to the
deployments (the practicality folks) to decide what software to use,
we just have to make it work with the rest of our system.
-Wade
From wadetb at gmail.com Mon Jan 5 09:16:54 2009
From: wadetb at gmail.com (Wade Brainerd)
Date: Mon, 5 Jan 2009 09:16:54 -0500
Subject: [Sugar-devel] [IAEP] Flash at Sugar Labs
In-Reply-To: <659C6A9C-6780-4373-8148-2A24F84E95AF@freudenbergs.de>
References:
<7087c32a0901041823i3ad3deb4q3b274d4f6edf29ab@mail.gmail.com>
<659C6A9C-6780-4373-8148-2A24F84E95AF@freudenbergs.de>
Message-ID: <7087c32a0901050616o68418605s5e2acc487247ae3e@mail.gmail.com>
On Mon, Jan 5, 2009 at 7:15 AM, Bert Freudenberg wrote:
> On 05.01.2009, at 05:24, John Watlington wrote:
>
>> On Jan 4, 2009, at 9:23 PM, Wade Brainerd wrote:
>>>
>>> Currently Sugar is incapable of running software which is not
>>> specifically designed for it.
>>
>> Sugar runs simpler SWF applications just fine, through the Browser.
>> They don't have to be "designed" for Sugar.
>
>
> I think this goes besides the original point of Bryan. He is well aware that
> software needs to be specifically designed for Sugar, and wether this is
> good or bad is not the current debate. The point is what tools one can use
> to implement a proper Sugar activity. Bryan says the tools many content
> developers are familiar with are HTML, Javascript, and Flash.
I agree completely - I proposed a swf-activity launcher script as the
solution, in my initial response to Bryan.
> I think it would be relatively easy to come up with an activity template
> that just has a subdirectory for SWF content. Creating an SWF activity then
> would involve copying the template, editing the meta data, putting the SWF
> content into the directory, zipping it up and voila, a nice XO bundle. That
> process could easily be done by a script, even on Windows.
I think the template should be built into and supported by the Sugar
dev team, rather than something that has to be copied around.
That way it's able to be updated and improved over time, and as better
Flash solutions become available we can incorporate them easily.
I agree with the rest of Bert's plan. It should be a PyGTK activity
with just an activity toolbar, which launches Gnash or Adobe Flash
into its canvas. It should also find the Flash persistence database
and copy it to/from the Journal.
A nice additional feature would be to make use of Jordan's screen
resolution dropper on the XO to allow Flash activities to run at
600x450, which would likely quadruple performance.
-Wade
From dvanassche at gmail.com Mon Jan 5 10:01:36 2009
From: dvanassche at gmail.com (David Van Assche)
Date: Mon, 5 Jan 2009 16:01:36 +0100
Subject: [Sugar-devel] [IAEP] Flash at Sugar Labs
In-Reply-To: <7087c32a0901050616o68418605s5e2acc487247ae3e@mail.gmail.com>
References:
<7087c32a0901041823i3ad3deb4q3b274d4f6edf29ab@mail.gmail.com>
<659C6A9C-6780-4373-8148-2A24F84E95AF@freudenbergs.de>
<7087c32a0901050616o68418605s5e2acc487247ae3e@mail.gmail.com>
Message-ID: <8cc423ef0901050701l166a3edei1b9087d5b3c6f4be@mail.gmail.com>
This might be of interest:
Salasaga is a GTK/Gnome based IDE used to create eLearning for
applications. With it, you take screenshots of your applications,
add highlights, text and external images, then generate learning
objects. Present output is in swf (flash) format.
It would certainly be useful for making flash based learning objects
for Moodle. The site for the soft is here:
http://www.salasaga.org/
kind Regards,
David Van Assche
On Mon, Jan 5, 2009 at 3:16 PM, Wade Brainerd wrote:
> On Mon, Jan 5, 2009 at 7:15 AM, Bert Freudenberg wrote:
>> On 05.01.2009, at 05:24, John Watlington wrote:
>>
>>> On Jan 4, 2009, at 9:23 PM, Wade Brainerd wrote:
>>>>
>>>> Currently Sugar is incapable of running software which is not
>>>> specifically designed for it.
>>>
>>> Sugar runs simpler SWF applications just fine, through the Browser.
>>> They don't have to be "designed" for Sugar.
>>
>>
>> I think this goes besides the original point of Bryan. He is well aware that
>> software needs to be specifically designed for Sugar, and wether this is
>> good or bad is not the current debate. The point is what tools one can use
>> to implement a proper Sugar activity. Bryan says the tools many content
>> developers are familiar with are HTML, Javascript, and Flash.
>
> I agree completely - I proposed a swf-activity launcher script as the
> solution, in my initial response to Bryan.
>
>> I think it would be relatively easy to come up with an activity template
>> that just has a subdirectory for SWF content. Creating an SWF activity then
>> would involve copying the template, editing the meta data, putting the SWF
>> content into the directory, zipping it up and voila, a nice XO bundle. That
>> process could easily be done by a script, even on Windows.
>
> I think the template should be built into and supported by the Sugar
> dev team, rather than something that has to be copied around.
>
> That way it's able to be updated and improved over time, and as better
> Flash solutions become available we can incorporate them easily.
>
> I agree with the rest of Bert's plan. It should be a PyGTK activity
> with just an activity toolbar, which launches Gnash or Adobe Flash
> into its canvas. It should also find the Flash persistence database
> and copy it to/from the Journal.
>
> A nice additional feature would be to make use of Jordan's screen
> resolution dropper on the XO to allow Flash activities to run at
> 600x450, which would likely quadruple performance.
>
> -Wade
> _______________________________________________
> IAEP -- It's An Education Project (not a laptop project!)
> IAEP at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>
From gregsmitholpc at gmail.com Mon Jan 5 10:27:05 2009
From: gregsmitholpc at gmail.com (Greg Smith)
Date: Mon, 05 Jan 2009 10:27:05 -0500
Subject: [Sugar-devel] possible additional talks for XOCamp2?
In-Reply-To: <1231131010.30071.14.camel@hitman>
References: <1231131010.30071.14.camel@hitman>
Message-ID: <496226C9.8030905@laptop.org>
Hi Bryan,
Both sound like very good subjects.
I have you down for two hours Monday afternoon:
http://wiki.laptop.org/go/XOcamp_2#Monday_January_12.2C_2009
My goal for the first day is to give an overview of the challenges faced
by deployments and how we hope to address them in release 9.1.0.
Hopefully your slot Monday can address Nepal's experience and next stage
plans.
After you on Monday afternoon, is a working meeting to define how we
ensure the latest Sugar is stable and how we include it in 9.1.0.
Then we cover the technical details of each 9.1 area Tues. and Wed.
Thursday and Friday are more open. John Gilmore is confirmed for
Thursday afternoon but otherwise those meetings are mostly open and can
be changed.
Do you want to take Friday AM 10AM - Noon or Thursday afternoon 3PM - 5PM?
Pick a slot and fill it in. Add a section below with more detail and
link to it from the calendar if you want to give people a chance to see
the agenda in advance.
I'm not sure how many sugar focused people will be there late in the
week but I expect you can get all the regulars from OLPC HQ at a minimum.
Thanks,
Greg S
Bryan Berry wrote:
> I would like to give the following talks at XOCamp2 if there is space in
> the schedule for them and others are interested. Please let me know if
> you would be interested
>
> 1. Evolution of a deployment organization.
>
> About the challenges of building a deployment team from scratch and
> lesson learned along the way. Not a very technical talk.
>
> 2. Karma - Not for Hackers, for Designers
>
> Talk about my still evolving ideas for a flash-based activity framework
> called Karma
>
>
From guillaume.desmottes at collabora.co.uk Mon Jan 5 11:39:21 2009
From: guillaume.desmottes at collabora.co.uk (Guillaume Desmottes)
Date: Mon, 05 Jan 2009 16:39:21 +0000
Subject: [Sugar-devel] File transfer in Telepathy
In-Reply-To: <1228240272.11241.24.camel@cass-lpt>
References: <1228240272.11241.24.camel@cass-lpt>
Message-ID: <1231173561.6722.38.camel@cass-lpt>
Le mardi 02 d?cembre 2008 ? 17:51 +0000, Guillaume Desmottes a ?crit :
This new release depends on glib 2.16, dbus 1.1.0 and
> libsoup-2.2.
I just released telepathy-salut 0.3.7 depending on libsoup-2.4 instead
of 2.2. This release also fixes some file transfer related bugs.
See
http://lists.freedesktop.org/archives/telepathy/2009-January/002719.html
for the announcement.
Regards,
G.
From bmschwar at fas.harvard.edu Mon Jan 5 12:07:38 2009
From: bmschwar at fas.harvard.edu (Benjamin M. Schwartz)
Date: Mon, 05 Jan 2009 12:07:38 -0500
Subject: [Sugar-devel] [IAEP] Flash at Sugar Labs
In-Reply-To: <7087c32a0901050616o68418605s5e2acc487247ae3e@mail.gmail.com>
References: <7087c32a0901041823i3ad3deb4q3b274d4f6edf29ab@mail.gmail.com> <659C6A9C-6780-4373-8148-2A24F84E95AF@freudenbergs.de>
<7087c32a0901050616o68418605s5e2acc487247ae3e@mail.gmail.com>
Message-ID: <49623E5A.3050504@fas.harvard.edu>
Wade Brainerd wrote:
> I think the template should be built into and supported by the Sugar
> dev team, rather than something that has to be copied around.
I strongly disagree. We should send the clearest possible message that
SWF, a language with no good free spec and no good free interpreter, is
not recommended, even if it is supported. Software Freedom is a key part
of the Sugar labs mission, both officially and in fact.
> A nice additional feature would be to make use of Jordan's screen
> resolution dropper on the XO to allow Flash activities to run at
> 600x450, which would likely quadruple performance.
We can do even better.
http://wiki.gnashdev.org/Release_0.8.5#Release_Goals shows XVideo scaling
support as one of the goals for the next Gnash, due in a month.
--Ben
From bryan at olenepal.org Mon Jan 5 12:59:52 2009
From: bryan at olenepal.org (Bryan Berry)
Date: Mon, 05 Jan 2009 09:59:52 -0800
Subject: [Sugar-devel] [IAEP] Flash at Sugar Labs
In-Reply-To: <8cc423ef0901050701l166a3edei1b9087d5b3c6f4be@mail.gmail.com>
References:
<7087c32a0901041823i3ad3deb4q3b274d4f6edf29ab@mail.gmail.com>
<659C6A9C-6780-4373-8148-2A24F84E95AF@freudenbergs.de>
<7087c32a0901050616o68418605s5e2acc487247ae3e@mail.gmail.com>
<8cc423ef0901050701l166a3edei1b9087d5b3c6f4be@mail.gmail.com>
Message-ID: <1231178392.12102.23.camel@hitman>
On Mon, 2009-01-05 at 16:01 +0100, David Van Assche wrote:
> This might be of interest:
>
> Salasaga is a GTK/Gnome based IDE used to create eLearning for
> applications. With it, you take screenshots of your applications,
> add highlights, text and external images, then generate learning
> objects. Present output is in swf (flash) format.
>
> It would certainly be useful for making flash based learning objects
> for Moodle. The site for the soft is here:
> http://www.salasaga.org/
>
> kind Regards,
> David Van Assche
This looks extremely neat. Thanks for the link David!
--
Bryan W. Berry
Technology Director
OLE Nepal, http://www.olenepal.org
From cjb at laptop.org Thu Jan 1 23:06:07 2009
From: cjb at laptop.org (Chris Ball)
Date: Thu, 01 Jan 2009 23:06:07 -0500
Subject: [Sugar-devel] How to Make Activity Designers Happy ,
Parts I and II
In-Reply-To: <1230861040.17108.4.camel__8009.18864920295$1230861178$gmane$org@hitman>
(Bryan Berry's message of "Thu, 01 Jan 2009 17:50:40 -0800")
References: <1230861040.17108.4.camel__8009.18864920295$1230861178$gmane$org@hitman>
Message-ID:
Hi Bryan,
> Sadly, Javascript can't use the Graphics Processing Unit like Flash
> can. Ouch,
The XO doesn't have much of a GPU, so I wouldn't be so worried about
this. Any Javascript renderer that backs onto cairo will get as any
other graphics on the XO.
> Many people will likely hate my promotion of Flash for learning
> activities. It's OK if you hate me and Flash. I do hope you
> recognize that we need a more developer-centric activity framework
> that uses web technologies.
Making activity development easier is an unarguably fine goal, but I
don't think there are any simple solutions. For example, do we even
have a Flash editor under Linux? Is the first instruction on how to
write activities for someone in the developing world going to be "First,
pirate a copy of Windows and Adobe Flash Professional, and then.."?
- Chris.
--
Chris Ball
From cjb at laptop.org Fri Jan 2 03:09:08 2009
From: cjb at laptop.org (Chris Ball)
Date: Fri, 02 Jan 2009 03:09:08 -0500
Subject: [Sugar-devel] How to Make Activity Designers Happy ,
Parts I and II
In-Reply-To: <1230874359.17108.16.camel@hitman> (Bryan Berry's message of
"Thu, 01 Jan 2009 21:32:39 -0800")
References: <1230861040.17108.4.camel__8009.18864920295$1230861178$gmane$org@hitman>
<1230874359.17108.16.camel@hitman>
Message-ID:
Hi Bryan,
> Developing learning activities requires the developer already know
> something about programming. In Nepal, China, India that means they
> have at least a pirated copy of Windows and possibly Adobe Flash.
> If they have linux, that means that some time ago they had pirated
> Windows which they used to learn about linux.
That sounds plausible, at least for pirated Windows. (I'm sure it's
much harder to get a copy of Flash.)
I'm not willing to incorporate "First, get a pirated copy of Windows
and Flash" into my instructions for activity development, though.
We're supposed to be combating the inequity that says "we can create
things on our computers because we're rich, but you don't get to do
that on yours without breaking the law because you're poor". That
inequity is just as much a part of the digital divide as everything
else we're trying to bridge over, in my opinion.
It feels important to me to be able to say "Here's a software platform
for you to start out with, and here's all of the software we used in
the process of making it, which means there's nothing stopping you
from learning to further it yourself". A true passing on of knowledge
from one group to another, as equals.
I imagine this is the kind of debate where no-one really changes their
mind; that's okay. As long as the viewpoint of software freedom as a
foundational principle for Sugar (even in the face of extra convenience)
is being represented and considered, I'm happy.
Thanks,
- Chris.
--
Chris Ball
From overbyte at earthlink.net Fri Jan 2 13:46:18 2009
From: overbyte at earthlink.net (Stanley Sokolow)
Date: Fri, 02 Jan 2009 10:46:18 -0800
Subject: [Sugar-devel] [IAEP] Flash development for the XO
In-Reply-To:
References: <1230861040.17108.4.camel__8009.18864920295$1230861178$gmane$org@hitman> <1230874359.17108.16.camel@hitman>
Message-ID: <495E60FA.4070400@earthlink.net>
Hi,
Chris Ball wrote:
> Hi Bryan,
>
> > Developing learning activities requires the developer already know
> > something about programming. In Nepal, China, India that means they
> > have at least a pirated copy of Windows and possibly Adobe Flash.
> > If they have linux, that means that some time ago they had pirated
> > Windows which they used to learn about linux.
>
> That sounds plausible, at least for pirated Windows. (I'm sure it's
> much harder to get a copy of Flash.)
>
> I'm not willing to incorporate "First, get a pirated copy of Windows
> and Flash" into my instructions for activity development, though.
>
I'm writing regarding the latest thread about using Flash as a
development platform for XO activities. Very recently, my attention
turned to Flash, or more specifically to Flex which is Adobe's platform
for development of Rich Internet Applications (RIA) that run on the
Flash Player virtual machine. (Flash is the system for development of
applications, mainly video animations on a timeline, in a highly visual
manner, whereas Flex is oriented toward programming GUI (graphical user
interface) applications, but both of them use the same underlying
technology of ActionScript language and the virtual machine embedded in
the Flash Player to execute the object code.) I considered Javascript
and the multitude of libraries built for it, but Flash seems to be a
better way for me to build robust, attractive, run-everywhere
applications. I won't go into the details of that decision, but here
are some things not mentioned yet in this discussion about Flash for the
future of OLPC software.
Adobe has opened the source of most of the Flash development kit and
provides it free-of-charge as a download of the kit called the Flex SDK,
which is a complete development kit for building ActionScript 3
applications except for the IDE (integrated development environment).
Adobe sells their Flash Builder IDE for about $300, but there's a free
open source IDE that's pretty good: FlashDevelop. FlashDevelop doesn't
have the what-you-see-is-what-you-get playback view of your code that is
included in Adobe's more featured Flex Builder, but you can accomplish
the same thing by compiling and viewing the results in your browser,
then returning to the FlashDevelop IDE, all of which is quick and easy.
Read about it at:
http://www.flashdevelop.org/wikidocs/index.php?title=Features . You
don't absolutely need an IDE to develop Flash programs, since you can
just write them in your favorite programming editor, but an IDE makes
life a little easier.
FlashDevelop only runs on Windows and .NET, but the resulting output
runs anywhere on the FlashPlayer. Flex (and FlashDevelop) lets you
develop the UI (user interface) using an XML language called MXML to
place the pre-built widgets on the screen and hook them to programmed
logic written as scripts in ActionScript, all embedded in an HTML page
to run in a browser that has had the Flash Player installed.
(ActionScript is Adobe's language, but it was based on the proposed next
version of Javascript which is still in development by the standards
organization.) As you know, FlashPlayer is almost ubiquitous, being
installed by most computer manufacturers and freely downloaded from
www.adobe.com . It's available for Windows, Mac, Linux, and Solaris.
There are free open-source libraries that work with ActionScript to
enhance what you can do, even some amazing 3d libraries such as Away3d.
(Check it out at www.away3d.org .) Although the source of the
FlashPlayer is not open, that should not be a deterrent to developing
for it. Anyone working with open source software is sorely aware that
open source software development is somewhat chaotic and doesn't in fact
produce software that runs everywhere without major problems. Having
one company provide the infrastructure in the form of FlashPlayer has
some advantages. FlashPlayer sounds like just a video player, but it's
far more than that. It is a virtual machine for running programs
compiled by the ActionScript compilers, such as the one included for
free in the Flex SDK. Adobe's web site has a great deal of tutorial and
reference information, including videos, about developing for the
infrastructure, so it's not necessary to buy a lot of books or take
expensive classes. The same development system can also be used to run
Flex applications outside of the browser like any other desktop
application, using the Adobe AIR player, also free to download with a
free AIR SDK at www.adobe.com/air .
However, Flash on the XO is not yet a rosy picture in my book.
Yesterday I posted my comments on devel at lists.laptop.org, which I quote
below.
Stanley Sokolow wrote to developers at devel at lists.laptop.org:
> Hi,
>
> I'm having problems: Adobe FlashPlayer doesn't detect the XO's built-in
> webcam so it can't transmit video out to the Internet on Flash-enabled
> web sites, and the Adobe Flash player on the XO freezes the popup
> right-click control panel. Gnash didn't work at all with a Flash-based
> web site we're interested in, so I went to the real FlashPlayer, latest
> version.
>
> I've been lurking here watching the comments on Gnash versus Flash while
> I tried to get my wife's XO playing nicely with a Flash-based RIA (rich
> internet application) site called www.vyew.com . (That's pronounced
> like "view".) Vyew is a collaborative whiteboard application with
> video, voice, and text chatting features in addition to the
> whiteboard. By whiteboard, I mean that several users can connect to
> the same page and collaborate on drawing sketches and typing text on the
> same screen, which is visible to all of the connected people. They
> can also activate their camera and microphone (if they exist) to carry
> on two-way conversations like Skype. She wants to use this for a
> remote tutoring activity where she interacts with students about math
> problems. We tried to get Paint and Colors activities to play nicely
> with various Sugar emulators (LiveCD, Sugar on Ubuntu, Sugar on Windows
> Vista) but they all had various problems seeing (presence detection) or
> collaborating. So we found this web site, Vyew. The Vyew site didn't
> load the Flash content on the web page with Browse and Gnash, so I
> installed the real Adobe Flash player on the XO. We have been largely
> successful with Vyew and Adobe FlashPlayer on the XO. Both computers
> can see each other's drawings collaboratively on the same page, but we
> ran into one problem that relates to Flash on the XO.
>
> The XO browser can see the webcam video stream from our Dell laptop
> running Vyew on the Dell's Vista browsers (MS IE & Firefox) and can hear
> the audio stream from the Dell, but I can't get Flash to activate the
> XO's camera. When I right-click on the Flash box in the web page, the
> Flash popup menu appears. I click the "settings" item. Adobe Flash
> Player control panel pops up as it should, but it is just frozen. I
> can't get it to flip to the other tabs to set the camera & microphone
> permissions. In fact, the panel won't even quit when I click the Close
> button. Nothing gets rid of it except reloading or leaving the web
> page. This was while running on the XO's Browse activity. I thought
> that maybe Opera for the XO would do better. No luck. Opera as
> installed from the wiki.laptop.org/opera instructions does not even play
> the Flash on the Adobe web site: www.adobe.com/products/flash/about ,
> nor any other Flash embedded in a web page. All that Opera shows is a
> gray rectangle where the Flash should be, no text saying to click to
> play the Flash. This is apparently a problem of Opera not interacting
> well with FlashPlayer, because the Opera plugin directories point to the
> very same plugin program file by symbolic linkage, so it's not a bad
> plugin file -- the Adobe plugin plays the Flash .swf embedded element
> with Browse, just not perfectly, but Opera doesn't play it at all.
>
> I submitted a comment to the Opera programmer who maintains the Opera
> blog about the OLPC version, but that blog has had very little activity
> in the past year so I'm not hopeful of any results from the Opera
> people. Has anyone here tried to run a recent release of Opera on the
> XO, not the very old version that was customized for the XO according to
> our wiki?
>
> For the record, here are the various versions I'm running: XO has build
> 767 of Sugar, the XO is one recently received from the G1G1 program
> through Amazon, the FlashPlayer is the one recommended on the
> wiki.laptop.org page:
> http://fpdownload.macromedia.com/get/flashplayer/current/flash-plugin-10.0.15.3-release.i386.rpm
> , the "about" Flash page reports the correct release 10,0,15,3 and so
> does the README in the flash-plugin folder on the XO, and uname reports
> that my XO's Linux version is 2.6.25-20080925.1.olpc.f10b654367d7065.
>
> Even without the 2-way video streaming, www.vyew.com is a nice
> application for collaboration over the Internet. Try it.
>
> Stan Sokolow
>
>
I should add that Opera works well with the same (latest) version of
FlashPlayer on my Ubuntu computer, so the bug must be in the old version
of Opera for the XO.
By the way, I have no connection whatsoever with Adobe or any other
software company for that matter. I'm just a self-taught computer
geek on a low budget, trying to maximize what I can do, minimize the
time it takes, and minimize the cost.
Stan
From overbyte at earthlink.net Fri Jan 2 14:20:11 2009
From: overbyte at earthlink.net (Stanley Sokolow)
Date: Fri, 02 Jan 2009 11:20:11 -0800
Subject: [Sugar-devel] More about Flash on the XO
In-Reply-To:
References: <1230861040.17108.4.camel__8009.18864920295$1230861178$gmane$org@hitman> <1230874359.17108.16.camel@hitman> <1230912293.17108.41.camel@hitman>
Message-ID: <495E68EB.6080508@earthlink.net>
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090102/62b653c6/attachment-0001.htm
From cjb at laptop.org Fri Jan 2 14:38:18 2009
From: cjb at laptop.org (Chris Ball)
Date: Fri, 02 Jan 2009 14:38:18 -0500
Subject: [Sugar-devel] [IAEP] How to Make Activity Designers Happy ,
Parts I and II
In-Reply-To: <7087c32a0901020930g3a529a23tbc789fb4bddf8574__17215.7903704376$1230917638$gmane$org@mail.gmail.com>
(Wade Brainerd's message of "Fri, 2 Jan 2009 12:30:48 -0500")
References: <1230861040.17108.4.camel__8009.18864920295$1230861178$gmane$org@hitman>
<1230874359.17108.16.camel@hitman>
<1230912293.17108.41.camel@hitman>
<7087c32a0901020930g3a529a23tbc789fb4bddf8574__17215.7903704376$1230917638$gmane$org@mail.gmail.com>
Message-ID:
Hi,
> I think Bryan's idea is wonderfully practical. What's more,
> it sounds easy to achieve. You just need a 'swf-activity'
> launcher, and a script to sugarize .SWF files into .xo bundles
> which launch as fullscreen activities.
Oh, that sounds good. I should clarify -- I don't have a problem
with anyone working on that launcher or making Flash applications for
learning that use it. The 'swf-activity' launcher could be little more
than the gtk-gnash binary, which we already install.
We're talking about "reworking the default activity framework", though,
and that setup is incompatible with the requirements I'd propose for
our framework, because it requires proprietary software and doesn't (as
far as I can see) allow activities to save work or offer collaboration
and sharing. If we recommended it in place of our current framework,
we would be gaining some convenience in the form of developer time at
the expense of much of the expressivity, power, and software freedom
that makes our platform meaningful in the first place.
So, I'd suggest that this goal (play Flash applications fullscreen)
happens independently of improvements on how we help people to write
Sugar activities. Does that make sense?
- Chris.
--
Chris Ball
From sascha-ml-ui-sugar-sugar at silbe.org Fri Jan 2 19:38:34 2009
From: sascha-ml-ui-sugar-sugar at silbe.org (Sascha Silbe)
Date: Sat, 3 Jan 2009 01:38:34 +0100
Subject: [Sugar-devel] Teaching typing and basic math on the XO
In-Reply-To: <7087c32a0901021620t76f42fcele8c97ed01cedc3d8@mail.gmail.com>
References: <1230874359.17108.16.camel@hitman>