Changes

===Sugar Digest===

===Sugar Digest===

1. activities.sugarlabs.org (ASLO) has been the subject of much discussion of the past few weeks. One thread has been in regard to making ASLO a place where not only Sugar developers upload their activities, but where Sugar learners upload the media objects that they create with Sugar activities. For example, a place for children to upload and share their Turtle Art projects or Physics simulations. A second thread has been in regard to whether or not to allow activities to be uploaded onto ASLO that contain non-Sugar dependencies. An example might be an architecture-specific binary file that is included in a .xo bundle or simply a dependence on a library that is not part of the core Sugar distribution. The arguments for such restrictions have to do with robustness and user experience. We don't want users to download activities that subsequently don't run, either because of an architecture mis-match or a missing dependency. We also want to be very careful about automatically pulling in dependencies because bandwidth and local storage are extremely limited for many Sugar users. However, from the beginning, Sugar has accommodated activities with dependencies external to the Sugar core: Etoy, Write, and Browse being three examples. And with the growth of the netbook market and innovations such as Sugar on a Stick, it is inevitable that Sugar users will be using a wide variety of architectures. (For example, OLPC is exploring the use of ARM processors in their laptops.) And, while we want to provide a consistent and substantial learning experience within Sugar itself, the extent to which we can be inclusive of other learning activities gives Sugar users the ability to reach further than they would otherwise. None of this suggests that we are abandoning the idea of a learning platform that provides a collection of affordances to the learner, such as the Journal, collaboration, and view source; Sugar (Sucrose and Fructose) is mostly written in Python with a consistent user experience across all of its activities; but our learning community should not have artificial walls and ceiling.

1. activities.sugarlabs.org (ASLO) has been the subject of much discussion of the past few weeks. One thread has been in regard to making ASLO a place where not only Sugar developers upload their activities, but where Sugar learners upload the media objects that they create with Sugar activities. For example, a place for children to upload and share their Turtle Art projects or Physics simulations. A second thread has been in regard to whether or not to allow activities to be uploaded onto ASLO that contain non-Sugar dependencies. An example might be an architecture-specific binary file that is included in a .xo bundle or simply a dependence on a library that is not part of the core Sugar distribution. The arguments for such restrictions have to do with robustness and user experience. We don't want users to download activities that subsequently don't run, either because of an architecture mis-match or a missing dependency. We also want to be very careful about automatically pulling in dependencies because bandwidth and local storage are extremely limited for many Sugar users. However, from the beginning, Sugar has accommodated activities with dependencies external to the Sugar core: Etoys, Write, and Browse being three examples. And with the growth of the netbook market and innovations such as Sugar on a Stick, it is inevitable that Sugar users will be using a wide variety of architectures. (For example, OLPC is exploring the use of ARM processors in their laptops.) And, while we want to provide a consistent and substantial learning experience within Sugar itself, the extent to which we can be inclusive of other learning activities gives Sugar users the ability to reach further than they would otherwise. None of this suggests that we are abandoning the idea of a learning platform that provides a collection of affordances to the learner, such as the Journal, collaboration, and view source; Sugar (Sucrose and Fructose) is mostly written in Python with a consistent user experience across all of its activities; but our learning community should not have artificial walls and ceiling.

In a post that ties the two threads together, Ben Schwartz wrote:

In a [http://lists.sugarlabs.org/archive/sugar-devel/2010-March/022819.html post] that ties the two threads together, Ben Schwartz wrote:

:If Sugar is working as intended, 99% of Activities will be crap. This is because the purpose of Sugar is to invite novices to engage actively in software development. Novices make bad stuff, and we want to install and run that stuff.

:If Sugar is working as intended, 99% of Activities will be crap. This is because the purpose of Sugar is to invite novices to engage actively in software development. Novices make bad stuff, and we want to install and run that stuff.