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

Bryan Berry bryan at olenepal.org
Fri Jan 2 14:46:03 EST 2009


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 <tomeu at sugarlabs.org>
> 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 <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
>         >
>         _______________________________________________
>         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



More information about the Sugar-devel mailing list