journal is hard + sugar and the digital age

[Erik Garrison]

On Thu, Oct 09, 2008 at 12:13:02PM -0400, Eben Eliason wrote:
> On Thu, Oct 9, 2008 at 10:15 AM, Carlos Nazareno <object404 at gmail.com> wrote:
> > Hi Tomeu. Some personal feedback:
> >
> >> 3) Basically - The journal is really hard for people/ kids to use over
> >> a longer period of time. Kids and teachers can't find things that they
> >> did unless it was done within the last 30 minutes.
> >>Could you please elaborate on the difficulties that people have when
> >>using the journal?
> >
> > I've experienced the same problem. Items tend to clutter up in the
> > journal over time, it's like viewing your entire web browsing history.
> > Its current implementation simply leads to information overload with
> > the accumulating number of entries.
> >
> > IMHO, the philosophy of "nothing gets forgotten" with the journal is a
> > bit flawed because as people we don't even naturally do that. We
> > selectively choose which information to remember and mark as important
> > and discard the rest because that's just information overload.
> 
> You're right on with this comment.  Of course, I don't think "nothing
> gets forgotten" is really what we're aiming for; in fact, we aim for
> much the opposite.  However, as it's currently implemented, you're
> right!  The Journal is actually supposed to retain everything you've
> done *quite recently* so that you can always go back and find, remix,
> resume, etc.  Experimentation is encouraged.
> 
> However, the very principles the Journal was designed around include
> the concept of memory, and particularly the fading thereof.  Over
> time, less used, unstarred, unimportant files will eventually be
> backed up and then removed (probably after confirmation, but perhaps
> you can opt out of the confirmation step) by the system, so that the
> further back in time you look, the less you have left, but the more
> relevant the remaining items are to your history with the laptop.
> 
> This is a very important aspect of the Journal that just hasn't had
> time to happen, yet.
> 

You acknowledge that the system is not functioning as well as it should
be in its curren state.  Please stop saying "we are going to do this"
and look for the simplest way to achieve a usable system for our usesr.
I will gladly help in this endeavor, but I am concerned by our security
system and the frequent implications that we are holding to old designs
that my ideas and motivation have no place in this effort.

I don't think we can incorporate the concept of memory and forgetting
into the Journal in a programmatic way.  Forgetting is as much a learned
skill as remembering, and attempting to replicate it in software seems
like a very difficult, if impossible, task.  I feel that we are tilting
at windmills if we believe we can reliably produce something so
incredible in any conceivable timeframe.

I positively advocate a simplification of our expectations about what
the Journal will do.  Just a system which consistently suggests (but
does not enforce) default, intelligent organizations for things in a
traditional filesystem, provides manual and automatic tagging support,
and indexes the text of written documents will be a giant step forward
in terms of reliability and interoperability with the outside world.
With metadata about files stashed in a database, such as time, date,
text (for indexing and search), tags, creating application, etc. we can
do everything the Journal is intended to do, but no sacrifice the
simplicity and reliability of the default filesystem in the process of
developing the Journal to its full capacity.

For this we only need to work on three sets of components:

 1) Journal -- a file browsing application which provides numerous views
onto the corpus of data the user creates and handles; views being
time-ordered, filtered, hierarchical (traditional), tag-based, etc.
Allowing other applications to manage files will let contributors create
or port existing systems to the Sugar environment to fulfill these
functions as well.

 2) Indexer -- a simple filesystem crawler that walks across the set of
directories to which users are expected to save data (e.g. not Activity
directories or hidden directories in /home) and executes plugin scripts
which produce indexable metadata and fulltext for use in later searches
by the user.  The scripts can have a standard IO format, such as used by
tracker, and can be installable by inclusion in Activity bundles.

 3) Watcher -- a filesystem watcher which uses inotify to watch for
changes in the set of directories to which the student writes data.  On
change, invokes the indexer, which then executes the corresponding
metadata / fulltext extraction scripts and adds the file in question to
the index accessible and searchable by the Journal.

I feel that we are moving in this direction, but to really get there so
much has to change in the architecture of Sugar that I am afraid that
this work will be unsupported and renegade in flavor.

I am furthermore frustrated by the tight integration of the Journal into
the window manager.  In particular, our security model has the effect of
preventing work on this issue that isn't supported by all the core
developers.  We can only have one file management application.  I am
afraid that I or another interested developer will implement such
systems but find they are rejected by the core developers, and it will
be impossible even for users desire to use them to easily do so.

Erik