<div><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; Installing a bunch of example images with the activity bundle sounds<br>&gt; like a really bad idea to me, given our space limitation
<br>&gt; (independently from the fact that you want them share between multiple<br>&gt; activities). Why don&#39;t we just make these available separately, as a<br>&gt; content bundle (.xol)? That way kids can install and uninstall these
<br>&gt; when they want through the journal.<br><br>Well, this seems to ignore the major intention of delivering initial<br>content on the system - getting the kids to learn by example. How<br>should they know they have to install something before they can start
<br>learning?</blockquote><div><br class="webkit-block-placeholder"></div><div>I think one difference here is the predominance of the format in question. &nbsp;Images, video, audio, and other &quot;primitive types&quot; of media will not be in short supply, and in fact the kids will be producing these in great quantity themselves. &nbsp;As such, there is no shortage of images that might be dropped on one of these puzzles.
</div><div><br class="webkit-block-placeholder"></div><div>Tutorials and examples, on the other hand, provide us with an unknown format for an activity that may or may not be readily discoverable without them in the first place. &nbsp;This is a different concern, and we definitely need to support this as well.
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Clicking an icon and getting an empty document was one of the major<br>problems Etoys had before the OLPC version. The current initial Etoys
<br>project (our &quot;launch&quot; screen with the 5 cloud buttons) at least<br>presents a couple of choices, and links to other projects that<br>demonstrate various parts of the system.<br><br>How would that be done if the examples have to be installed first?
<br>Even leaving aside the problem of security concerns forbidding direct<br>linking to objects in the journal, how *do* we provide a seamless<br>introduction?</blockquote><div><br class="webkit-block-placeholder"></div><div>
Well, we&#39;ve talked about this a lot, and the proposal on the table at the moment is to allow instantiating new objects/documents/projects with examples. &nbsp;That is, when opening a new Etoys project, the user may have the option to select an empty project or any from a list of examples. This option should only appear once, upon instantiation, at which point the selected project becomes the object represented by the activity instance; more examples could be launched by creating new instances.
</div><div><br class="webkit-block-placeholder"></div><div>The best way to understand this is to consider each running instance as an object itself, ignoring the notion of applications which open a bunch of separate files, perhaps even at the same time. &nbsp;Allowing any form of &quot;open&quot; functionality that isn&#39;t an import function (such as importing an image into the current write document) actually &quot;swaps&quot; the object represented by the running instance, which we want to avoid. &nbsp;By making this a parameter of the creation of the instance, this dilemma goes away.
</div><div><br class="webkit-block-placeholder"></div><div>- Eben</div></div><br>