On 8/26/07, Bert Freudenberg <[EMAIL PROTECTED]> wrote: > > On Aug 24, 2007, at 1:25 , Marco Pesenti Gritti wrote: > > > On 8/24/07, Carlos Neves <[EMAIL PROTECTED]> wrote: > >> - The images bundled are art done by kids on the MaMaMedia site. They > >> are examples and can be trimmed down considerably, but they are also > >> reasons to be proud for the kids that did them, so I guess that if we > >> can keep the whole bunch, we will. > > > > Installing a bunch of example images with the activity bundle sounds > > like a really bad idea to me, given our space limitation
We want to be careful with our space, especially in the core systems whose components are never to be swapped out. When it comes to activities, this should be seen as a constraint to focus artistry and selection, not an absolute limitation. We have more than enough space to include a good set of examples with every activity. > > (independently from the fact that you want them share between multiple > > activities). Why don't we just make these available separately, as a > > content bundle (.xol)? That way kids can install and uninstall these > > when they want through the journal. The idea is that these images should always be available when the activity launches; either downloaded / available as part of its bundle or already on the system. 'make available separately' doesn't capture this dependency. Content bundles are not currently meant to be bundles that hang around waiting for Activities to use them. They are a stopgap for bundles that don't include their own executable, but are viewable in a browser, until we work out a better unified bundle definition that covers these different use cases. A hack to get something like what one might want here : browse to a content bundle with images, and download each one individually; have the Journal automatically note their mime-type, and make that available to activities requesting same. A similar hack that doesn't require the journal to efficiently process thousands of files all the time: make directories of shared media available (read-only) to all activities, and let at least signed activities add their media to such directories. > Well, this seems to ignore the major intention of delivering initial > content on the system - getting the kids to learn by example. How > should they know they have to install something before they can start > learning? Right. It would be a mistake to imagine that an Activity is complete as soon as it compiles and passes functional tests. > Clicking an icon and getting an empty document was one of the major > problems Etoys had before the OLPC version. The current initial Etoys > project (our "launch" screen with the 5 cloud buttons) at least > presents a couple of choices, and links to other projects that > demonstrate various parts of the system. And it is a dramatic improvement, especially when people are playing around on their own without a walkthrough. > How would that be done if the examples have to be installed first? > Even leaving aside the problem of security concerns forbidding direct > linking to objects in the journal, how *do* we provide a seamless > introduction? The basic questions here have nothing to do with security. There is thread convergence with Carla's recent thread on how to provide a concise introduction to Etoys without a personal tutorial... Some combination of illustrative projects and explicit help files (or an intro) is a start. (I'm not sure in Etoys's case how to sequence the different intros that are available.) SJ _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
