2013/9/13 David Farning <dfarn...@activitycentral.com>: > On Thu, Sep 12, 2013 at 6:54 PM, John Watlington <w...@laptop.org> wrote: >> >> On Sep 10, 2013, at 5:04 PM, Sameer Verma wrote: >> >> On Thu, Sep 5, 2013 at 7:51 PM, Caryl Bigenho <cbige...@hotmail.com> wrote: >>> >>> One of the things that makes Sugar the ideal learning platform for >>> children (and youth) is the wonderful compatibility of so many of the >>> Activities ... both from Activity to Activity and from student to student. >>> This facilitates the sort of learning we are all hoping to see more of... >>> creative problem solving, project based learning and cooperative learning. >>> Without this ability to integrate parts of projects, it would just be >>> another collection of apps. >>> >> >> I did not want to muddy the picture by injecting my own viewpoint, but now >> that I've heard from others (on and off list) it is clear that the split is >> driven by the role they play in the ecosystem. >> Most technologists have come up with reasons why they don't think a complete >> Sugar experience would work on Android. Therefore, activities must run like >> any other app on Android. On the other hand, as Caryl said, "Without this >> ability to integrate...it would just be a collection of apps". >> >> Somewhat knowing the limitations of what can be done with Sugar stuff on >> Android, but disregarding that for a minute, I would say that Sugar as a >> *platform* is an experience. It has a UI. It has a UX. Everything from the >> Zoom interface to the activities to the Journal is Sugar. We have taken the >> original "Sugar on the OLPC XO" experience and replicated that to the >> classmate PC, SoaS, and other spins and distros, but in none of these cases >> did we break the holistic Sugar experience. Now, along comes a popular OS, >> and because the tech parts don't fit, we are advocating breaking up the >> pieces and taking whatever flies. Memorize will become one of the few >> hundred thousand apps on Android. >> >> I disagree. >> >> It's like saying we'll do the cat sprite from Scratch, but nothing else. >> It's like saying we'll do the birds and pigs from Angry Birds, but not the >> slingshot. Sugar, without all its pieces isn't worth the trouble. >> >> >> Sameer, >> I disagree somewhat with your thesis (and am very glad you started this >> discussion.) >> >> From a technological standpoint, it is actually probably easier to implement >> what you describe: >> Sugar as a monolithic Android application, which takes over the entire user >> interface when >> launched. The reason I never considered it seriously was the larger >> ecosystem. >> >> The reason to move to Android from Linux is two-fold: >> - Chip vendors are dropping Linux support in favor of Android. The cheap >> chinese ARM >> vendors only support Android. >> - Android/iOS are where application development is happening. There is a >> much larger >> community of Android developers than Linux or Sugar developers. >> >> The hope was to provide the infrastructure underlying Sugar (the Journal >> datastore and >> collaboration) as Android services, encouraging their use in new Android >> applications. >> In this model, the Journal is another Android application, accessing the >> Journal datastore service. >> New Sugar activities written in HTML should be capable of running in Sugar >> on Linux >> or as Android activities (although perhaps with different execution >> wrappers). >> In this manner, perhaps we can enlarge the Sugar community with developers >> mainly >> targeting Android. > > Just to clarify: > 1. OLPC-A's intention is to create a HTML5+JS framework for creating > Sugar Activities.
A small correction: activities using web technologies has been discussed for a while in the Sugar community, and is now being actively implemented as part of Sugar roadmap. > 2. Sugar Activities created using this framework will run equally well > on both 'Sugar for linux' and Android. > 3. This requires two separate abstraction layers "wrapper" one for > Sugar on linux and one for Android. > 4. These abstraction layers make Sugar Services such as collaboration > and the journal available within the HTML5+JS framework. > > Is there an implementation plan and roadmap available? Are there > sufficient resources committed to these projects to see them through > to completion? > >> If we pursue Sugar as a single Android application, >> with embedded >> Python activities, we are isolating ourselves from the Android community. >> >> The danger of this approach is the loss of an integrated UX. This could be >> addressed >> by customizing the home UI, in the same manner that the XO tablet has a >> custom home UI >> implementing the Dreams interface, but that would require "rooting" the >> tablet in some manner. >> But the native Android UI isn't that bad... >> >> Cheers, >> wad >> >> >> _______________________________________________ >> Devel mailing list >> de...@lists.laptop.org >> http://lists.laptop.org/listinfo/devel >> > > > > -- > David Farning > Activity Central: http://www.activitycentral.com > _______________________________________________ > Devel mailing list > de...@lists.laptop.org > http://lists.laptop.org/listinfo/devel -- .. manuq .. _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep