Project Name: olpc-bundler has been set up

[Eben Eliason]

On Thu, Aug 14, 2008 at 2:56 PM, Erik Garrison <erik at laptop.org> 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 <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

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
>