[Bookreader] [Sugar-devel] Book bundles and Read
sayamindu at gmail.com
Mon Aug 3 08:21:22 EDT 2009
On Sat, Aug 1, 2009 at 7:47 AM, Samuel Klein<meta.sj at gmail.com> wrote:
> 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
>> teach curriculum, or some Turtle Art projects teaching the idea of
>> or a mix of both along with a book or two and a Labyrinth mind-map of
>> notes. What happens if an Activity wants to use the ObjectChooser to pick
>> object buried in someone else's collection.
> On Fri, Jul 24, 2009 at 6:57 PM, Sayamindu Dasgupta <sayamindu at gmail.com>
>> 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.
> I disagree here. In theory, it is nice to imagine you might only need to
> solve a large # of similar interface and design problems once for every
> situation. In practice, it is really difficult to design a smooth, fast,
> rewarding interface for a general problem : a focused use case, and the
> freedom to make something work brilliantly for that case without having to
> demonstrate that it is a good design decision for all other parallel use
> cases, helps get something useful.
> I would expect to regularly want my bookshelf to be able to browse through
> hundreds of files at once, searching and autocompleting through their
> specific index; sort by book-specific metadata fields; and handle a
> collection 90% of which I am not storing locally -- possibly requesting a
> book from a repository off-disk, possibly keeping a fixed size on-disk
> library and having a process for queueing old books for local removal.
> Yes, an Ideal Journal might include these features. But I expect a Read
> <--> Get IA Books activity might deal with this over the next year or two
> much more effectively than an a Journal being pulled in many directions.
I do agree with you that the Journal should not take care of business
like searching through external repositories, in fact, IMHO, the
Journal should not do anything that makes it try to connect to the
Internet, or even a school server (a hard dependency on network should
be avoided as much as possible). However, given that, I think,
mimetype specific custom metadata support in Journal should give us a
reasonable way to manage books stored locally - and if no one else is
working on it right now, I can take a shot.
What I do not want to do at this stage is do the book management
inside Read itself (it is Read, and not Manage Books :-). A separate
activity is required for retrieving books from external sources, and I
think Get IA Books is a great start, and can be quickly extended to
support something like Feedbooks (though probably we need to consider
Feedbook's ToS at http://www.feedbooks.com/termsofuse before trying to
go ahead with the coding).
We may even want to support OPDS catalogs (compressed as well as
uncompressed) as journal objects, opened and browsable via Get IA
Books or its later form.
More information about the Bookreader