[sugar] Journal integration design for Measure Activity

[Eben Eliason]

On 10/21/07, Albert Cahalan <acahalan at gmail.com> wrote:
> > > That's OK, but don't waste effort on compression.
> > > Standards say you use the pax format, or at least
> > > something like tar or cpio.
> >
> > Interesting point.  Perhaps, with our filesystem, we should always
> > prefer something other than zip for bundles?  Tar would be a good
> > pick.
>
> It's also because general-purpose compression algorithms
> do almost nothing with audio data. Ideally the jffs2 compression
> would also be avoided.

True.

> > > You can put sample rate info in the header of a *.wav file.
> > > This is really the perfect format for your data.
> >
> > I'm not sure I necessarily agree with that.  As a text file, it would
> > be possible to crack open logs with a text editor, or in the future, a
> > spreadsheet activity of some kind.  I'd much prefer to keep the data
> > in simpler formats, when there aren't negative consequences to doing
> > so.
>
> The simplest format for audio data is an audio file.
> Basic *.wav data is really simple. It's a 44-byte header
> followed by the raw data.

Obviously I know little about the .wav format, so perhaps you are
right.  My only point is that, as far as I understand it, the logs are
really just a list of samples (time, value), which are at least a
second apart.  Is there really a reason to use an audio format for
what amounts to a simple list of tuples?

> There are numerous tools that handle *.wav files,
> including for data analysis.
>
> There was some plan for an "export as" functionality;
> support for other formats could be done that way.

That's true.

> > > > 3) It may also be possible that within a session of Measure,
> > > > no logs be made. However the user have selected some settings
> > > > with which he/she was making some measurements. For example
> > > > DC/AC mode, gain setting and a time base setting etc. The user
> > > > may want to resume such a session from the journal. How should
> > > > such details be handled ? Do I need to write them down into a
> > > > text file ? The settings comprise of states of 3 toggle buttons
> > > > and 2 sliders.
> > >
> > > Whatever you do, don't spam the journal.
> >
> > This is strictly metadata about a particular entry that will exist
> > anyway.  I don't see any spam problems here.
>
> The entry should not exist. It is spam.
>
> Besides annoying the user, it consumes resources.
> The flash will wear out. Power is required to write.
> Picture the tired little kid cranking.

Sorry, I misread the first time.  You are exactly right; if there are
no logs, the entry should NOT be created at all.  Please refer also to
https://dev.laptop.org/ticket/4365 for my comments on this issue.

> > > I just finished deleting a huge pile of spam from my journal.
> > > Well, not counting the two things that refused to be deleted.
> > > This was not an enjoyable task. As with an email inbox, I run
> > > a risk of deleting something I want to keep as I wipe things
> > > out. This stupid busy-work chore should never be needed.
> >
> > Agreed.  There are a few things that can and should be done up front,
> > but in the long term the Journal is going to perform intelligent
> > collapsing of versions and also provide automated "garbage removal"
> > (or at least, garbage flagging) so that this process isn't a burden on
> > the owner, but a natural extension of the core ideas of the Journal as
> > a filesystem.
>
> Ah. Anybody here who has never lost an email because
> it was automatically deleted by a spam filter, or because
> they were too careless while trying to delete the flood?
>
> This is not a good path to go down for regular storage.

This is an essential path when there is so little storage on these
machines.  The design of the Journal and the idea of temporal
granularity has been a consideration from day one.  I agree this is
not what we're used to, but I also don't think that it's necessarily a
bad course.  If this is an intrinsic part of the system, it won't be a
"surprise" to kids as they go along.  We have some mechanisms in place
which allow them to indicate which files to completely skip in this
tidying process.

Also, as mentioned, the system will be naturally versioned.  The
computer can make some decisions about which entries are similar and
"colllapse" these versions from older projects, which no longer need
the same granularity.

All of this, of course, will likely have global preferences which
prevent this for those who choose to do all management on their own.

> > > A few buttons is nothing. If it gets to be dozens of buttons
> > > or more, then you might add a "save settings" button. Hopefully
> > > you can save this with the activity itself, rather than putting
> > > more junk onto the desktop^H^H^H^H^H^H^Hjournal.
> >
> > The whole point of the system is to prevent the need for manual
> > saving, and to emphasize the idea of sessions, which means that
> > session state is really important.  In any case, this is still
> > independent of the spamming problem, which arises from "empty" entries
> > (which should indeed be avoided) and from frequent use of an activity.
> >  Still, if the emphasis on sessions takes hold, one should more often
> > than not be resuming an old entry, rather than making a new one all
> > the time.
>
> I don't think this works.
>
> First of all, you're saving at random points. You're not also
> saving the undo history. (which would be bad for both privacy
> and storage reasons) Without positive action by the user to
> indicate that the current version of the user's data is desirable,
> there is a chance that desirable state will be replaced by
> undesirable state.

This is a non-issue when versions are in place, which is very high
priority in the upcoming releases.  The new version won't overwrite
the previous version at all.

> Second of all, starting an activity fresh is simply much easier
> than starting it from the journal.

This is most certainly an invalid assumption.  Specifically for
reasons like the list of stored state above, returning to a known
state can save time.  Moreover, for many activities, including labs,
you really do want to continue a project you've been working on.  You
continue a drawing, you write another few paragraphs of a story, and
you can also take a few more measurements for a lab you're working on.

> Third of all, freshness is good. Experimentation is discouraged
> if it leaves a trail of junk. Nobody likes cleaning up old messes.
>
> Even with just the intended stuff, the journal is kind of
> unmanagable and confusing. Adding spam into the mix
> does not help one bit.

These points are hard ones to argue.  There are many features of the
Journal as planned that aren't there, and many aspects of it that
surely haven't been tested enough in practice.  These are all new
ideas, and maybe some of them aren't good.

Still, I think that the trail of junk can be managed in time.  Maybe
that quick experiment from last week is just what you need today, and
it would be great to have it accessible without having to worry about
what is saved and what isn't all the time, during the experimentation.
 Of course, if it isn't touched, starred, tagged, or otherwise
interacted with for a period of time, the Journal can flag it as a
candidate for removal.

I think we'll have to think about the system holistically before
dumping some of these core ideas.

- Eben