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

Wade Brainerd wadetb at gmail.com
Fri Jan 2 15:00:08 EST 2009


I'm not sure about Gears, but I have worked with the Flash persistence stuff
before - you're right, it's quite convenient.  It would be great to build
support for finding the storage file and copying it to/from the Journal.

It could even be done automatically by the WebActivity class (or else a
separate FlashActivity class if we want to avoid loading Firefox) class,
making it transparent to the Flash programmer.

-Wade

On Fri, Jan 2, 2009 at 2:46 PM, Bryan Berry <bryan at olenepal.org> wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090102/ad693221/attachment-0001.htm 


More information about the Sugar-devel mailing list