[Sugar-devel] Book bundles and Read

[Gary C Martin]

Hi Sayamindu,

On 23 Jul 2009, at 19:02, Sayamindu Dasgupta wrote:

> On Thu, Jul 23, 2009 at 9:03 AM, Gary C Martin<gary at garycmartin.com>  
> wrote:
>
> <..snip snip>
>
>>
>> Hmmm. The down side of this is that you end up with 1 Journal zip  
>> bundle
>> holding a large number of books... So, I resume this zip bundle,  
>> pick one of
>> the many books and start reading. I assume the single Journal entry  
>> is now
>> remembering this one book and page I'm now reading. So now I want  
>> to read
>> another book in the same bundle, do I loose the reference to the  
>> book and
>> the page I was on before? Jump through some new UI hoops to flag  
>> the book
>> and bookmark the page? It feels like walking into a Library, but  
>> only being
>> able to read one book at a time. Successful Journal entries are the  
>> ones
>> that store Activity state for some small slice of the goal, one  
>> book, not
>> the whole library of congress.
>>
>
> I think Read can be able to handle that. It means some extra work in
> the code, but it can be possible to extend the metadata in such a way
> that the state for each and every book in the bundle/collection is
> remembered.

Of course you can hack on Read and make it handle all this bundle/ 
collection stuff :-) but my argument is Read should not really be  
doing this extra step.

Journal needs to cover these features (whatever they resolve to be).  
Every activity author should not be inventing various implementations  
of a "book shelf" UI concepts for dealing with a monoculture  
'collection' of objects. Imagine if I wanted to put together a  
'collection' of Physics simulations to teach curriculum, or some  
Turtle Art projects teaching the idea of vectors, or a mix of both  
along with a book or two and a Labyrinth mind-map of topic notes. What  
happens if an Activity wants to use the ObjectChooser to pick an  
object buried in someone else's collection.

A combination of a Journal grid view and correctly tagging objects  
would pretty much solve the UI side; with perhaps a bundle format  
(maybe repurpose .xol) so that downloading one auto extracted to a  
number of tagged Journal entries; and the reverse perhaps being true  
where you select N existing Journal entries and "send to -> ..."  
causes them to be zipped up as a .xol and transferred as a single item.

James' existing working solutions, Read EText, and Get Internet  
Archive Books (which BTW already downloads nice PDFs for Read to  
read), focus on using existing online resources for downloading new  
content to the Journal. This seems like a good Sugar Activity design  
pattern for cases where large online monocultures of resources already  
exist. Are you looking to fold his work into Read**?

**I would have been great if Read had been extended, rather than a  
separate Read EText Activity created, but I guess that's water under  
the bridge now.

Regards,
--Gary