Journal needs to cover these features (whatever they resolve to be). Every<br>
> activity author should not be inventing various implementations of a "book<br>
> shelf" UI concepts for dealing with a monoculture 'collection' of objects.<br>
> Imagine if I wanted to put together a 'collection' of Physics simulations to<br>
> teach curriculum, or some Turtle Art projects teaching the idea of vectors,<br>
> or a mix of both along with a book or two and a Labyrinth mind-map of topic<br>
> notes. What happens if an Activity wants to use the ObjectChooser to pick an<br>
> object buried in someone else's collection.<br>
<br>On Fri, Jul 24, 2009 at 6:57 PM, Sayamindu Dasgupta <span dir="ltr"><<a href="mailto:sayamindu@gmail.com" target="_blank">sayamindu@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div></div>I do agree with you that it is the Journal which should be doing this,<br>
and not Read (except for maybe accessing online catalogs - though I<br>
think James has a better approach with his Get IA Books activity. It's<br>
just that, I'm a bit frustrated with the current state of the journal<br>
(especially for handling collections), and while xol-s are a great<br>
idea in theory, the practice of jumping through the browser<br>
(especially if Rainbow is enabled) is extremely crappy, IMHO :-).<br>
However, after going through all the mails, especially the links which<br>
Aleksey sent, I think it may be worthwhile to devote my coding cycles<br>
to the Journal instead.<br>
<div></div></blockquote><div><br><br>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.<br>
<br>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.<br>
</div></div><br>S.<br>