[Bookreader] [Sugar-devel] Book bundles and Read

[Samuel Klein]

 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.

On Fri, Jul 24, 2009 at 6:57 PM, Sayamindu Dasgupta <sayamindu at gmail.com>wrote:

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

S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/bookreader/attachments/20090731/f8cd0287/attachment.htm