Project Name: olpc-bundler has been set up

[Erik Garrison]

On Thu, Aug 14, 2008 at 02:06:14PM -0400, Eben Eliason wrote:
> On Thu, Aug 14, 2008 at 1:57 PM, Erik Garrison <erik at laptop.org> 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
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?

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