Re: [IAEP] Sugar on Android via HTML5
On Thu, Sep 12, 2013 at 4:54 PM, John Watlington wrote: > > On Sep 10, 2013, at 5:04 PM, Sameer Verma wrote: > > On Thu, Sep 5, 2013 at 7:51 PM, Caryl Bigenho 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.) > > Disagreement is good. It brings out perspectives :-) > 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. If we pursue Sugar as a single Android application, > with embedded > Python activities, we are isolating ourselves from the Android community. > > I see your point. It's clearer now that the concepts of Sugar should be pushed into Android (or any other platform for that matter). > 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... > > Let me expand on this point. There may be room for an "and" instead of an "either/or". Most of my research is on the user perspective of software, as opposed to the developer perspective. Users who are far removed from the developer bits tend to make adoption decisions based on *perceived* attributes as opposed to the real ones. So, instead of looking at APIs, protocols, code, they tend to look at things like relative advantages, compatibility with work environment, ease-of-use, voluntariness, etc. (See https://en.wikipedia.org/wiki/Diffusion_of_innovations#Rogers.E2.80.99_5_Factors ) Now, in schools, the "voluntariness" will be low, in that the school/education system dictates what needs to be used in the classroom. However, when the machine goes home, "voluntariness" will kick in. If they have been using Sugar in the past, "compatibility" will kick in, and so on. So, to ease a transition, even if the
Re: [IAEP] Sugar on Android via HTML5
On Fri, Sep 13, 2013 at 7:51 AM, David Farning wrote: > On Thu, Sep 12, 2013 at 6:54 PM, John Watlington wrote: >> >> On Sep 10, 2013, at 5:04 PM, Sameer Verma wrote: >> >> On Thu, Sep 5, 2013 at 7:51 PM, Caryl Bigenho 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. > 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? I just wanted to follow up this thread. I find it interesting because the answer depend a bit on the person asking the questions. Is the person asking the questions: 1. An OLPC hater who is going to hate. 2. A muggle who is not capable of understanding OLPC. 3. A person who has proven that they support the OLPC vision while occasionally questioning the Association's stewardship of that vision. >> 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
Re: [IAEP] Sugar on Android via HTML5
On Fri, Sep 13, 2013 at 11:56 AM, Manuel Quiñones wrote: > 2013/9/13 David Farning : >> On Thu, Sep 12, 2013 at 6:54 PM, John Watlington wrote: >>> >>> On Sep 10, 2013, at 5:04 PM, Sameer Verma wrote: >>> >>> On Thu, Sep 5, 2013 at 7:51 PM, Caryl Bigenho 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. Yes, This is also figures prominently in my risk analysis. It appears that three Sugar developers are paid by OLPC: Manq, Gonzalo, and Walter. Please correct me if I am wrong or this has changed. Is OLPC-A in a position to commit these resources until the project is completed? >> 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 custo
Re: [IAEP] Sugar on Android via HTML5
2013/9/13 David Farning : > On Thu, Sep 12, 2013 at 6:54 PM, John Watlington wrote: >> >> On Sep 10, 2013, at 5:04 PM, Sameer Verma wrote: >> >> On Thu, Sep 5, 2013 at 7:51 PM, Caryl Bigenho 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 >> Devel@lists.laptop.org >> http://lists.laptop.org/listinfo/devel >> > > > > -- > David Farning > Activity Ce
Re: [IAEP] Sugar on Android via HTML5
On Thu, Sep 12, 2013 at 6:54 PM, John Watlington wrote: > > On Sep 10, 2013, at 5:04 PM, Sameer Verma wrote: > > On Thu, Sep 5, 2013 at 7:51 PM, Caryl Bigenho 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. 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 > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > -- David Farning Activity Central: http://www.activitycentral.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Sugar on Android via HTML5
On Thu, Sep 12, 2013 at 7:54 PM, John Watlington wrote: > > On Sep 10, 2013, at 5:04 PM, Sameer Verma wrote: > > On Thu, Sep 5, 2013 at 7:51 PM, Caryl Bigenho 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. 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 > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > My two cents: To add to Caryl's point about tools vs applications, there is no reason why we can port the tool-like nature of the core Sugar apps to Android. Solving the datastore problem means we can interoperate between objects with these tools... a Sugary approach that is largely missing in Android. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Sugar on Android via HTML5
On Sep 10, 2013, at 5:04 PM, Sameer Verma wrote: > On Thu, Sep 5, 2013 at 7:51 PM, Caryl Bigenho 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. 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 Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Sugar on Android via HTML5
On Tue, Sep 10, 2013 at 11:04 PM, Sameer Verma wrote: > On Thu, Sep 5, 2013 at 7:51 PM, Caryl Bigenho wrote: > >> Hi... >> >> I have also been waiting patiently (well, not really very patiently) for >> some news about Sugar coming to Android. So far, I have heard nothing new. >> So I guess it isn't too late to throw my educator's opinion into the mix... >> 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. >> Thanks for "listening" >> Caryl >> >> > Hi Caryl, > > Thanks for writing back. I am a bit surprised that I got more off-list > responses than on-list ones. 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. How it > will get done (if it will get done) is another story, and I wish we would > hear more about it onlist. > Well said! Cheers, Christoph > cheers, > Sameer > > -- >> From: sve...@sfsu.edu >> Date: Thu, 5 Sep 2013 13:14:59 -0700 >> To: i...@lists.sugarlabs.org; devel@lists.laptop.org >> Subject: [IAEP] Sugar on Android via HTML5 >> >> >> So, I've been mulling this for some time now. At work we are looking into >> using FireFoxOS as a platform for HTML5 apps in some of our courses. It's >> exciting that there is some momentum on the HTML5 activities in Sugar. >> >> What I'm unsure about is the implementation. Outside of the classic Sugar >> shell and activities (say, on a XO), are we envisioning the whole Sugar >> experience on Android, UI and all, or are we looking to have Sugar >> activities running on Android (with appropriate mods) but as yet another >> app? >> >> Has there been any conversation on this that I missed? >> >> cheers, >> Sameer >> -- >> Sameer Verma, Ph.D. >> Professor, Information Systems >> San Francisco State University >> http://verma.sfsu.edu/ >> http://commons.sfsu.edu/ >> http://olpcsf.org/ >> http://olpcjamaica.org.jm/ >> >> ___ IAEP -- It's An Education >> Project (not a laptop project!) i...@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/iaep >> > > > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > > -- Christoph Derndorfer volunteer, OLPC (Austria) [www.olpc.at] editor, OLPC News [www.olpcnews.com] contributor, TechnikBasteln [www.technikbasteln.net] e-mail: christ...@derndorfer.eu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Sugar on Android via HTML5
Hi Sameer, 2013/9/10 Sameer Verma : > On Thu, Sep 5, 2013 at 7:51 PM, Caryl Bigenho wrote: >> >> Hi... >> >> I have also been waiting patiently (well, not really very patiently) for >> some news about Sugar coming to Android. So far, I have heard nothing new. >> So I guess it isn't too late to throw my educator's opinion into the mix... >> 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. >> Thanks for "listening" >> Caryl >> > > Hi Caryl, > > Thanks for writing back. I am a bit surprised that I got more off-list > responses than on-list ones. 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. How it > will get done (if it will get done) is another story, and I wish we would > hear more about it onlist. > > cheers, > Sameer > >> >> From: sve...@sfsu.edu >> Date: Thu, 5 Sep 2013 13:14:59 -0700 >> To: i...@lists.sugarlabs.org; devel@lists.laptop.org >> Subject: [IAEP] Sugar on Android via HTML5 >> >> >> So, I've been mulling this for some time now. At work we are looking into >> using FireFoxOS as a platform for HTML5 apps in some of our courses. It's >> exciting that there is some momentum on the HTML5 activities in Sugar. >> >> What I'm unsure about is the implementation. Outside of the classic Sugar >> shell and activities (say, on a XO), are we envisioning the whole Sugar >> experience on Android, UI and all, or are we looking to have Sugar >> activities running on Android (with appropriate mods) but as yet another >> app? >> >> Has there been any conversation on this that I missed? We are slowly getting closer to Sugar Android. We are working as a community in a best-effort basis, and all depends on how many people gets involved. So thanks for joining the discussion. We reached some goals already: - we have web activities running over Sugar GTK as first-class citizens. - we are documenting as we go http://developer.sugarlabs.org/ - and today I published a first draft of the API http://markable.in/file/fe27c384-1a38-11e3-b539-984be164924a/ that is implemented in GTK to allow web activities, and which needs to be implemented in Android to allow the same. Cheers, -- .. manuq .. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Sugar on Android via HTML5
On Thu, Sep 5, 2013 at 7:51 PM, Caryl Bigenho wrote: > Hi... > > I have also been waiting patiently (well, not really very patiently) for > some news about Sugar coming to Android. So far, I have heard nothing new. > So I guess it isn't too late to throw my educator's opinion into the mix... > 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. > Thanks for "listening" > Caryl > > Hi Caryl, Thanks for writing back. I am a bit surprised that I got more off-list responses than on-list ones. 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. How it will get done (if it will get done) is another story, and I wish we would hear more about it onlist. cheers, Sameer -- > From: sve...@sfsu.edu > Date: Thu, 5 Sep 2013 13:14:59 -0700 > To: i...@lists.sugarlabs.org; devel@lists.laptop.org > Subject: [IAEP] Sugar on Android via HTML5 > > > So, I've been mulling this for some time now. At work we are looking into > using FireFoxOS as a platform for HTML5 apps in some of our courses. It's > exciting that there is some momentum on the HTML5 activities in Sugar. > > What I'm unsure about is the implementation. Outside of the classic Sugar > shell and activities (say, on a XO), are we envisioning the whole Sugar > experience on Android, UI and all, or are we looking to have Sugar > activities running on Android (with appropriate mods) but as yet another > app? > > Has there been any conversation on this that I missed? > > cheers, > Sameer > -- > Sameer Verma, Ph.D. > Professor, Information Systems > San Francisco State University > http://verma.sfsu.edu/ > http://commons.sfsu.edu/ > http://olpcsf.org/ > http://olpcjamaica.org.jm/ > > ___ IAEP -- It's An Education > Project (not a laptop project!) i...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/iaep > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
