[Sugar-devel] Book bundles and Read

[Sayamindu Dasgupta]

On Fri, Jul 24, 2009 at 2:14 AM, Gary C Martin<gary at garycmartin.com> wrote:
> 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.
>


I do agree with you that it is the Journal which should be doing this,
and not Read (except for maybe accessing online catalogs - though I
think James has a better approach with his Get IA Books activity. It's
just that, I'm a bit frustrated with the current state of the journal
(especially for handling collections), and while xol-s are a great
idea in theory, the practice of jumping through the browser
(especially if Rainbow is enabled) is extremely crappy, IMHO :-).
However, after going through all the mails, especially the links which
Aleksey sent, I think it may be worthwhile to devote my coding cycles
to the Journal instead.

> 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 have plans on working on James's activity (I would probably try to
not restrict the activity to the Internet Archive), and I'm waiting
for the OPDS standard to mature a bit more before looking seriously
into online content aggregation.

> **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.
>

I agree - however, there is a large amount of code sharing that goes
between the two projects, and I'm in the middle of adding a extra
layer between Read's "view" widget and Evince, so that at some point,
Read would be able to handle Etexts as well, reusing James's code.


Thanks,
Sayamindu


-- 
Sayamindu Dasgupta
[http://sayamindu.randomink.org/ramblings]