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

[Tomeu Vizoso]

On Fri, Jan 2, 2009 at 20:30, Bryan Berry <bryan at olenepal.org> 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 <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
>
>