<div><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">>> - The images bundled are art done by kids on the MaMaMedia site. They<br>>> are examples and can be trimmed down considerably, but they are also
<br>>> reasons to be proud for the kids that did them, so I guess that if we<br>>> can keep the whole bunch, we will.<br>>><br>><br>> Installing a bunch of example images with the activity bundle sounds
<br>> like a really bad idea to me, given our space limitation<br>> (independently from the fact that you want them share between multiple<br>> activities). Why don't we just make these available separately, as a
<br>> content bundle (.xol)? That way kids can install and uninstall these<br>> when they want through the journal.</blockquote><div> </div><div>Well done Marco! I came up with this in bed last night and thought it hit the nail on the head, excited to suggest it, and it was already here waiting for me. I agree with this idea. If the media is not an integrated part of the activity itself, then a content bundle makes a lot of sense, and eliminates the redundant data and other problems.
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Well, that is by far the best idea I've heard on the shared content<br>issue! So I could provide the data as a separate bundle and kids use it
<br>from the Journal. And, if I can get my way with tagging and listing<br>stuff from the datastore programatically I can even keep the categorized<br>view in the activities...</blockquote><div><br class="webkit-block-placeholder">
</div><div>I have to apologize as well, since I really haven't had time to test out all of the various activities that are under development. It's truly fantastic that so many of the points I suggested in my little example are already underway!
</div><div><br class="webkit-block-placeholder"></div><div>That said, the one point I'm going to continue to fight for is to rid the UI for these activities of any internal list of images altogether. The Journal is perfectly suited for tagging, starring, searching and filtering everything (and will be accessible through a chooser), so I really don't see a reason to require this bar. Let the activity be solely about actually doing the puzzle, and let the management of images etc. be left up to our standard object chooser, which will be consistent, powerful, and secure and save you the coding trouble and screen real estate.
</div><div><br class="webkit-block-placeholder"></div><div>Like I said, each puzzle is it's own object, so each puzzle should really only need to have a reference to its own single image. This will give you more space, too, so that you can use the entire screen area for putting the puzzle together. The list of files is unneeded fluff, since chances are I'm not going to change the picture on a puzzle I've half completed. If I did decide to do that I might as well just create a new puzzle instance and start there, right?
</div></div><br><div>- Eben</div>