Eben Eliason 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 > > (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. > > > 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. > > Well, that is by far the best idea I've heard on the shared content > issue! So I could provide the data as a separate bundle and kids > use it > from the Journal. And, if I can get my way with tagging and listing > stuff from the datastore programatically I can even keep the > categorized > view in the activities... > > > 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! > > 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. > > 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? > > - Eben
Heh, you always make things sound so logical and obvious :) Ok, so the suggested workflow has a somewhat deeper change than I had envisioned yesterday. You say that a half completed puzzle should not need to have it's picture changed. Granted, that makes sense, but while searching for the correct image I may try multiple ones, so what I do with a timer is detecting a game action (moving a piece) to start it automatically, which is perfect to remove the button for opening a new image... Open a puzzle, get a popup asking for the image (through the Journal), show the image in the puzzle. A button to 'Select another' is presented. Start working on the puzzle, the 'Select another' disappears. Drop an image on a new puzzle loads that image. But what if you drop an image on a running puzzle? Do I: - save the current state and open the new image - request that a new instance is spawned (will I be allowed to?) - ignore the drop. - Open the new image as if the puzzle activity had been started anew. What do you think would best fit the intended UI workflow? _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
