<div><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">But if you don't dislike any of the now 2, but potentially more<br>activities that share images between them, you'll end up having a lot of
<br>wasted space, but of course the file hashing and linking would take care<br>of that.</blockquote><div><br class="webkit-block-placeholder"></div><div>What space would be wasted? Like I said, I think you only need a few images as a base. For these activities you're talking about, the content of the image doesn't seem to be essential to the activity itself. You could ship 3 images or so with each and let the kids provide the rest.
</div><div><br> </div><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Think of 'My Own Images' like Bookmarks are on a browser. You don't<br>store the content, you don't see the whole set of available data, you
<br>just mark them as 'cool'. Maybe there is tagging in the datastore<br>objects and I never crossed it? That would work really great and without<br>ever needing to do special kungfu or corner cases.</blockquote><div>
<br class="webkit-block-placeholder"></div><div>But bookmarks are created from the browser because that's where you go to browse pages. Kids can tag and star their photos when they take them. Adding a complicated file structure for managing photos inside what is otherwise a very lightweight activity shouldn't be necessary. The Journal does in fact depend heavily on the notion of tagging, and as mentioned there's even an integrated "starring" feature which let's the kids identify their favorite things within it.
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">It's a 'personal preference' thing, the bookmarks. You really like that<br>image of an XO completely dismantled, so you use it for everything...
<br>but then again, maybe user tags would work better? If the user feels so<br>inclined, he/she/it can tag images and apply that as a filter when<br>selecting an 'external' image.<br><br>There is an extra piece of information I didn't give you, which is the
<br>fact that images are categorized. I have a folder that holds folders<br>(categories) that holds images. You have a list of categories presented<br>to you and a separate widget that holds one image of the selected<br>category and has left/right arrows to walk through the other. 'My Own
<br>Images' is a special category.</blockquote><div><br class="webkit-block-placeholder"></div><div>Again, I still think this is entirely over engineering the problem. There should be a few base images (even just one?) and no need for this complex hierarchy or record of images (or a sidebar at all?). We've also been eliminating hierarchy in many cases, and I think that the "My Own Images" category is really what it's all about. The laptops are going to ship with lots of materials and a virtual library where the kids can find photos (and videos, sounds, texts, etc) of anything they want, so there's not much need for each activity to bundle their own library of media. When I want to do a different puzzle, I could select a new one from the Journal (via drag'n'drop or a chooser). The chooser itself will only show me images in the first place, likely with thumbnails, and it will have a search and filter field so I can quickly type "cat" (instead of browsing through categories) and select the "starred" filter to find my favorite photo of my cat in a flash.
</div><div><br class="webkit-block-placeholder"></div><div>Since we are changing the filesystem and its access so drastically, we're also dedicated to making interactions with it meaningful and simple for developers so that they don't have to jump through hoops to do their own management unless it's essential to the activity. For the most part, the more we can take advantage of these common choosers and the idea of tagging/filtering the stronger the whole system will be on the whole.
</div><div><br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><div>As another small tangent, the laptops depend on the notion of sessions, especially in the face of potential collaboration. As such, any management except that around a particular session is unwanted. Consider this use case: I open a jigsaw puzzle. I start playing the default image of a fish by myself, and then I share it and work on it with my friend for a while. We make some good progress. Later I want to do my own, so I start a *new* instance of the jigsaw puzzle (read this as I make a new jigsaw puzzle). On this one I drop a photo of my family, and I don't share it, because it's personal. Tomorrow, when I see my friend again, I go back to the Journal and we open the puzzle of the fish we were working on yesterday, continuing right where we left off.
</div><div><br class="webkit-block-placeholder"></div><div>You see, in this way I can have a bunch of different puzzles, each with it's own image, and with a different set of participants, and being in a different state of completion. Each instance of the activity literally *is a different puzzle* so to speak. Even before collaboration is available, this fits with our multi-instance/saved-session model, and it makes it more clear why the image associated with any given instance of the activity is a more intimate thing, and doesn't require the overhead of lists or managed sets of files at all. (This is why I suggest only a single default image...there's just one puzzle in the box, so to speak.)
</div><div><br class="webkit-block-placeholder"></div><div>Hopefully this example will turn your world upside down for a bit. We look at activities in a way that's quite different from many other platforms. =)</div>
<div><br class="webkit-block-placeholder"></div><div>- Eben</div><div><br class="webkit-block-placeholder"></div></div>