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 <[email protected]> > 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 <[email protected]> > 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!) > > [email protected] > > http://lists.sugarlabs.org/listinfo/iaep > > > _______________________________________________ > Sugar-devel mailing list > [email protected] > http://lists.sugarlabs.org/listinfo/sugar-devel > -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) [email protected] http://lists.sugarlabs.org/listinfo/iaep
