On Thu, Aug 14, 2008 at 2:56 PM, Erik Garrison <[EMAIL PROTECTED]> wrote: > On Thu, Aug 14, 2008 at 02:06:14PM -0400, Eben Eliason wrote: >> On Thu, Aug 14, 2008 at 1:57 PM, Erik Garrison <[EMAIL PROTECTED]> wrote: >> > On Thu, Aug 14, 2008 at 01:34:58PM -0400, Eben Eliason wrote: >> >> For clarification, is this a tool meant to be used by content >> >> providers on non-XO machines, or an activity for use in Sugar? >> >> >> > >> > Content providers. >> > >> >> I ask because, ever since we first designed the Journal, we've been in >> >> need of an activity (which should be called "Bundle") which is >> >> specifically designed to manage a variety of archive formats (zip, >> >> tar, gz, etc.). This activity is designed to provide an interface >> >> which allows organization of files and directories (in a hierarchical >> >> tree view), and can open or create bundles of any kind, or >> >> import/export individual items from the Journal. It's meant to be >> >> generic, so that any random bundle downloaded or copied to the XO can >> >> be opened, but it could certainly be given some special buttons or >> >> features which assist in the creation/editing of library/activity >> >> bundles on the XO. >> > >> > For the past several days I've jokingly been describing a hypothetical >> > activity called 'File', which subversively violates the design principle >> > of nothing-is-a-file implied by our current data manipulation system >> > (Journal) by allowing import and export of files from the datastore into >> > the regular filesystem. >> > >> > Strangely, this is exactly what you are describing. I will be happy to >> > work on it following my return. But it is not what olpc-bundler is; >> > olpc-bundler is a repo for content-related scripts. >> >> Well, that's not exactly what I'm describing. I'm interested in a >> particular activity which advertises support for archive formats, such >> that a freshly downloaded zip archive from any given website can be >> "opened" up, and its contents extracted directly to the Journal as new >> entries (or vice versa) for later use. That is, Bundle provides a way >> to move things into and out of these Bundle objects which live in the >> Journal, not a way to move them between the Journal and the >> Filesystem. >> >> It so happens that these structures frequently contain (and require) >> internal hierarchy, but I want to retain the notion that each Bundle >> instance is, effectively, a "box" with "stuff" in it. This is >> distinctly different, in my mind, from a general purpose file browser. >> >> I think there is a separate place for a "File" activity, which >> actually presents a true hierarchical view of the whole machine. I >> hope that future enhacements to the Journal expose the users documents >> in such a way that they could be browsed in this fashion, without need >> for import/export functionality. We'll see. olpcfs strives toward >> this goal. > > I started talking about the File activity because I am interested in a > deeper question. Why do we not default to the storage formats that
I understand your interest. In fact, I agree there is room for such an activity. But I don't want it conflated with Bundle, and let's please talk about it in a separate thread. The need for a Bundle activity remains with or without another view of the Journal. > exist in the rest of the computing world? These formats are utilized > frequently in computing because they abstract from complex sets of data > and make them manageable for human eyes and minds. I see no evidence in > my own experience that these organizational patterns (specifically > hierarchies) are insufficient or inappropriate for use by students. > Have there been studies which demonstrate this? As Ben mentioned, there are many places where tags/search are taking the place of more formal structures: Gmail, Delicious, Spotlight, and many others among them. The Journal has a pretty crappy interface into this at the moment, and naming/tagging isn't emphasized like it needs to be, but I think there is lots of potential here, still. That doesn't mean that we couldn't have a "File" activity which reveals a different view on the Journal. - Eben > If anything, the lack of hierarchical organizational systems in the > Journal makes things more confusing for users. Can you reasonably > expect to navigate more than 20 or 30 different entries without indexing > and search? When I have an unorganized (physical) box of stuff with > more than about this number of things in it, I start losing things in > the mess. I am presented with this view of any usb key I ever pop into > an XO. > > Things are different on a computer's storage media, because we can > employ software to improve the situation; but no matter how clever, this > software cannot read minds. Where automagic indexing fails to capture > user intent, what are users expected to do? Encouraging them to use > organizational hierarchies seems to be an entirely sensible, and > constructive, fallback, and it matches what we must do in the real world > to manage sets of things with more items than the number of fingers we > have. > > Erik > _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
