[Bookreader] [Sugar-devel] Book bundles and Read
tomeu at sugarlabs.org
Sat Aug 1 10:53:27 EDT 2009
On Sat, Aug 1, 2009 at 04:17, 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 don't see much value right now in speculating whether those features
will come first from the journal or from activities. I agree that it'd
be best if they appeared in the journal, and also agree it's better
that they appear first in activities rather than not having them at
But it all will depend at the end on who is willing to do the work and
at which level. Doing so in activities makes it less complicated for
the lone coder because can just code it, upload the bundle to ASLO and
announce it. Doing it in the journal will benefit more use cases, but
agreement with the rest of the community is needed before it can be
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
More information about the Bookreader