On Fri, Jan 2, 2009 at 20:30, Bryan Berry <[email protected]> wrote: > On Fri, 2009-01-02 at 19:18 +0100, Tomeu Vizoso 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? > > Presently, we do the following to run flash activities on the XO > > 1) download the Firefox3.xo bundle > 2) change the activity.info file > 3) change some of the file and directory names to reference > EPaathActivity instead of FirefoxActivity > 4) copy the swf (flash) files to ./activity/Activity/Activities (I know > it's ugly > 5) change the firefoxactivity.py > ff = [ './firefox' ] > to > ff = [ './firefox', './activity/Activity/Activities/OurSWF.htm']
Doesn't sound too complicated. How is it working right now? Which are the biggest issues? How do you envision this should be done instead? >> 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 > > Again, this requires people to learn python, a whole new language that > they don't necessarily use at work. We need to enable developers to be > very productive in just 2-3 hours per week. For them to be productive > they need to be using tools they are already familiar w/. > > Python is a tool popular among sysadmins and hackers. It is great tool. > But folks who develop web UIs use css, html, javascript, and flash. I > highly doubt that will change in the near or distant future. These are > people we need to recruit as activity designers. I guess I was unclear in my proposal. What I was talking about is creating a set of tools that the web developers would use. A python coder would write and maintain them and the web developers would use them to deploy their work. Regards, 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 >> > > -- > 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
