Hi James, On Tue, Apr 7, 2009 at 4:40 PM, James Simmons <jim.simm...@walgreens.com> wrote: > Since two of my Activities are referred to by name in your proposal I > suppose I should have an opinion on it, but I don't fully understand the > proposal.
I'd definitely like to hear your opinion. Also, please don't interpret this proposal as a critique of your activities, but consider how they might work better for content creators in the described system. > It sounds like you want to mix content and Activity in the > same bundle. So I guess you could write some sort of presentation using > HTML and JavaScript and bundle it up like an Activity that contains a > pointer to the Browse component needed to use it? Yeah, exactly. The idea is that there is a blurring of content and activity already, it's impossible to tell which is which. http://xent.com/~bsittler/yay-bee-see.html is a good example of this. So are many Flash programs. I want a way for "Content" to appear on the Home view along with the activities. Users in school systems are likely to have a set of important content on their XOs (math textbooks in PDF, etc) and it should not be hidden in the Journal. > You mention that Activities like Read, Read Etexts, etc. don't create > content, and thus are not like real Activities. That is currently true, > but lately I've been thinking of adding an Annotation feature to Read > Etexts which would let the user attach notes to individual pages of the > etext, as well as highlight passages with a yellow background (like > marking up a book with a hi-lighter pen). The notes and highlight > coordinates would be stored in as a collection of objects which would be > pickled and the pickle file would be stored in a Zip file along with the > original etext. So students assigned to read an etext could create > their own content in the form of notes and highlights and share these > with other students along with the text. That sounds great! My idea doesn't limit that though, in fact it encourages it. The intent is to allow all forms of content to have more activity-like features. > Originally Read and the rest did not appear in the Activity ring, and > the only way to launch them was to resume a Journal entry with the > supported MIME type. This was a source of frustration to me because my > own Activities make use of Zip files and there are at least three > Activities that use them: Read Etexts, View Slides, and Etoys. I was > constantly launching Etoys when I wanted to launch one of my own > Activities. What I really wanted was to have my documents display the > icon of the Activity needed to read that and launch that Activity when > resumed. Having the Activity launched from the ring and open that ugly > dialog solved that problem for me in two ways: Agreed. What my proposal allows is for someone to make a zip file of Animal slides (renamed as AnimalSlides-1.xo) with an activity.info indicating *which content viewer (aka activity) should open it*. The slides would appear with an icon in the home view. To me, this sounds like exactly what you were hoping for - so long as people are willing to make content available as .xo files. > So yeah it's ugly, but it gave me a way to do something I really wanted > to do. What would be nice is if the Journal let you specify a default > program to open a given Journal entry that otherwise would only be known > by its MIME type. I could download a Zip file from Gutenberg, then open > the Journal entry information page. Right now the launch button shows a > menu of all the Activities that can be used to open it and you pick one > from that menu. But what if there was a similar menu that let you > choose the default Activity, and once you chose it that icon was used > for the entry in the Journal? Zip files used in Etoys could be given > the Etoys icon, slide collections the View Slides icon, etc. I agree that handling of plain MIME objects in the Journal could be better. One way to deal with this would be to offer a Bundler activity which takes zip files and/or loose files and packages them into Unified bundles. The created bundles would have their "open with" set in activity.info. > I'm not sure why I'd want a content bundle that worked the way you > describe "Slides Content Viewer" and "Etexts Content Viewer". Etexts > contained in Zip files can already be downloaded from Gutenberg, and > slide collections are just images in a Zip file. It takes some work to > create these, but less than creating a bundle would be. I guess that depends on what tools are available for creating bundles. FWIW, bundles can be distributed on activities.sugarlabs.org while regular zip files need some other distribution mechanism. > I could see the point of an HTML bundle. Gutenberg has books with > illustrations in HTML format and making a bundle would give you a way to > read these offline. Yeah. HTML and SWF based bundles were the core requirement that drove this proposal, but it became clear at some point that it applied to other content types as well. Regards, Wade _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel