[Sugar-devel] web-based activities (was Re: [IAEP] How to Make Activity Designers Happy , Parts I and II)

[Bryan Berry]

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 <bryan at olenepal.org> 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.
> >
> > <strong>But Which Developers?</strong>
> >
> > 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
> > <u>designers</u>. 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. <a
> > href="http://en.wikipedia.org/wiki/Pygtk">PyGTK</a> won't take over the
> > world nor will VB.net.
> >
> > The popular term for this triumvirate of technologies is <a
> > href="http://en.wikipedia.org/wiki/AJAX">AJAX</a>, 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 (<a
> > href="http://en.wikipedia.org/wiki/Actionscript">Actionscript</a>) and
> > XML (<a href="http://en.wikipedia.org/wiki/MXML">MXML</a>).
> >
> > 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 <a
> > href="http://wiki.fossnepal.org/index.php?title=The_FOSS_Nepal_Community">FOSS Nepal</a> community has <a href="http://softwarefreedomday.org/Competition2008">won the award</a> 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 <em><strong>expensive</strong></em> to produce.
> >
> > <strong>Open-Source is Expensive</strong>
> >
> > 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:
> >
> > <ol><li>Give the programmer maximum flexibility</li><li>Fully exploit
> > the XO's hardware features </li><li>Mesh nicely with Sugar</li></ol>
> >
> > 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:
> >
> > <ol>
> >        <li>Allow activity designers to quickly build activities utilizing
> > widely-used tools.</li>
> >        <li>Quickly reward effort with working behavior</li>
> >        <li>Mesh nicely with the Sugar UI</li>
> > </ol>
> >
> > <strong>It's OK to be Opinionated</strong>
> >
> > 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 <a
> > href="http://en.wikipedia.org/wiki/Convention_over_Configuration">Convention Over Configuration</a>, 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,"
> >
> > <ul>
> >        <li>Where it's at: HTML, CSS, Javascript, and *gasp* Flash</li>
> >        <li>Nepal's Content Development Experience</li>
> >        <li>Aren't Kids going to create all learning activities so we don't
> > have to?</li>
> > </ul>
> >
> > <em>
> > Bryan Berry is the Technology Director of <a
> > href="http://www.olenepal.org">OLE Nepal</a> and deadbeat co-editor of
> > OLPCNews.com. Christopher Marin contributed his knowledge about all
> > things web to this article</em>
> >
> >
> >
> > 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 <em>happy</em>.
> >
> > 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
> > <a href="http://code.google.com/p/v8/ ">V8 javascript</a> compiler and
> > Apple's investment in <a
> > href="http://en.wikipedia.org/wiki/WebKit">Webkit</a>. 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 <u>KARMA</u>,
> > 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