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 <sayami...@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.
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel