[IAEP] How to Make Activity Designers Happy , Parts I and II

[Costello, Rob R]

I like the idea of minimising the path between effort and reward for as
many as possible 

as a time poor educator, albeit not in a developing country, the effort
of learning new technologies before I can contribute seems too steep,
much as I would like to 

(I had hoped to run some Sugar classroom trials, like Bill, but found
that too hard to schedule this year - I didn't have a suitable teaching
load in the 2nd half of the year when to make that work - too many other
new things occurring as well) 

While Flash is not open source it can usually be decompiled - I
decompile a few games with kids and we look at the maths etc - change
gravity in games etc; have hacked some extra things into LineRider from
the decompiled source code 

A lot of kids here are pretty interested in flash - having taught
themselves the visual side - and ask me about coding in it since they
know it's behind flash games etc  

On the other hand I don't know that learning the coding side of
actionscript is that easy(?)  for anyone who is also time poor(?)  - its
got quite java like in recent versions, for better or worse. I like it,
but it took a fair while for something like this www.brainshapes.com 

Developing an activity would definitely take more than visual animation
skills- important as they are -  so would need flash coding skills (and
the licensing issue is vexed - Gnash is a player only?  - could kids
even build a swf?)

And flash can certainly be a cpu hog if there is constant animation 

But I can see your pragmatic thinking - surf where the waves are - let
the visual and web skills sort of people play (those who have never
said, its a trivial hack to...)   :) 

Cheers

Rob 
Who is at zero points on the meritocracy of practical contribution, so
feel free to ignore



> -----Original Message-----
> From: iaep-bounces at lists.sugarlabs.org [mailto:iaep-
> bounces at lists.sugarlabs.org] On Behalf Of Bryan Berry
> Sent: Friday, 2 January 2009 12:51 PM
> To: iaep; sugar
> Subject: [IAEP] How to Make Activity Designers Happy , Parts I and II
> 
> 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">Conven
ti
> on 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

Important - This email and any attachments may be confidential. If received in error, please contact us and delete all copies. Before opening or using attachments check them for viruses and defects. Regardless of any loss, damage or consequence, whether caused by the negligence of the sender or not, resulting directly or indirectly from the use of any attached files our liability is limited to resupplying any affected attachments. Any representations or opinions expressed are those of the individual sender, and not necessarily those of the Department of Education and Early Childhood Development.