journal is hard + sugar and the digital age

[Tomeu Vizoso]

On Thu, Oct 9, 2008 at 6:55 PM, Erik Garrison <erik at laptop.org> wrote:
> 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.

No idea about what security has to do here.

The journal development has stalled because a fundamental part of it
(the datastore) hasn't had resources assigned to it. Don't ask me why.

You're continually mixing implementation and design issues, which
makes this discussion much more difficult than it already is.

I don't think there's much interest in discussing that the current
implementation sucks, we all agree here. What we would like to discuss
and would welcome your contributions, is how the design can be
improved in such a way that a much better implementation can happen
soonish. Several people are contributing usefully to this discussion,
why do you think you are not able to?

> 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 don't think we aim to actually replicate any brain function. We
"just" want to give the user tools that assist him in better managing
his data in a space with restricted capacity.

> 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'm really surprised now. You are saying that you cannot fruitfully
participate in discussions about the journal future, but at the same
time you have just described a design that most people around here
would broadly agree with. What support do you expect from us, that we
summon a couple hundreds of fairies and put them to work on the
journal?

> I am furthermore frustrated by the tight integration of the Journal into
> the window manager.

I don't know if this is funny or depressing. Please glimpse through
the journal code (it's not big) and tell me where it has any
dependency on the window manager. Don't worry looking for dependencies
on Journal in the window manager itself, because we run an unmodified
Matchbox. I'd like to know why do you feel the need to make such crazy
assertions, I don't think this helps in any way.

> In particular, our security model has the effect of
> preventing work on this issue that isn't supported by all the core
> developers.

Again, I don't see what security has to do with all this.

> We can only have one file management application.

Can you elaborate? We'd prefer for our users to have just a simple way
to manage their data, but if you think that the Sugar design should
make easier for people to plug-in different journals, etc., then you
can propose changes and send patches. Actually, Marco has done work
recently in that direction. Must be because he's coding that he
doesn't write that many emails, maybe I should do the same...

> 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.

Several people have found ways to contribute their work to Sugar. Why
do you fear that you won't be able to? It's not that we don't have our
own views on what is best nor that we let people change everything as
they like, but we welcome any help we can get and are ready to make
lots of compromises to get it.

Regards,

Tomeu