[Sugar-devel] How to Make Activity Designers Happy , Parts I and II

[Bryan Berry]

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