Journal needs to cover these features (whatever they resolve to be). Every<br>
&gt; activity author should not be inventing various implementations of a &quot;book<br>
&gt; shelf&quot; UI concepts for dealing with a monoculture &#39;collection&#39; of objects.<br>
&gt; Imagine if I wanted to put together a &#39;collection&#39; of Physics simulations to<br>
&gt; teach curriculum, or some Turtle Art projects teaching the idea of vectors,<br>
&gt; or a mix of both along with a book or two and a Labyrinth mind-map of topic<br>
&gt; notes. What happens if an Activity wants to use the ObjectChooser to pick an<br>
&gt; object buried in someone else&#39;s collection.<br>
<br>On Fri, Jul 24, 2009 at 6:57 PM, Sayamindu Dasgupta <span dir="ltr">&lt;<a href="mailto:sayamindu@gmail.com" target="_blank">sayamindu@gmail.com</a>&gt;</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&#39;s<br>
just that, I&#39;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 &lt;--&gt; 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>