[sugar] Journal integration design for Measure Activity

[Eben Eliason]

On 10/22/07, Albert Cahalan <acahalan at gmail.com> wrote:
> On 10/22/07, Eben Eliason <eben.eliason at gmail.com> wrote:
> > On 10/22/07, Albert Cahalan <acahalan at gmail.com> wrote:
> > > On 10/22/07, Eben Eliason <eben.eliason at gmail.com> wrote:
> > > > On 10/21/07, Albert Cahalan <acahalan at gmail.com> wrote:
> > >
> > > > > 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?
> > >
> > > I don't see this data as being tuples at all.
> > > It's not even x-y data.
> > >
> > > Timing is perfectly regular. Doing an FFT on irregularly
> > > spaced data is awkward, though possible.
> > >
> > > Audio file converters already exist. Loading and storing is fast.
> > > The storage is efficient.
> >
> > Well, then it's a list of values (with a known sample rate).  Still, I
> > don't see this as audio.  What harm is there in making it a text file
> > which ANY text editor could open?  Moreover, treating it as audio data
> > is going to group it as under a search for all things of type "Audio",
> > which it isn't.  I wouldn't expect my graph of the past week's daily
> > temperature changes to be an audio file.
>
> If you sampled hourly or more often, then it should do fine
> as a TamTam instrument. :-)

Interesting.

> There is no usable text editor anyway. (BTW, if a Terminal
> one will do, I suggest "joe". It's UTF-8 aware, can show a
> help window while you work, is based on explicit block
> operations rather than hidden ones, and it highlights the
> current block.)

Write can certainly open plain text files, even though it isn't
designed as a plain text editor.  Nonetheless, I agree that there will
be a market for a basic text editor at some point.  I think nano is
installed for CL use at the moment.

> Anyway, a *.wav file is unquestionably efficient in every way.
> This matters anywhere, but especially on the XO.
>
> > > Fresh: hit frame button, click on activity
> > >
> > > Restart: hit home button, click on journal, spend time hunting
> > > around in the disorganized mess, click to get the activity going,
> > > manually delete the old data and restore default settings
> >
> > But consider, Restart: press search key, type 'temp', click to resume
> > first (most recent) entry.  You've now opened the science lab on
> > weather you started last Friday, with a couple temperature reading
> > logs and all of the necessary settings restored as well, with no need
> > for more setup overhead.
>
> I could see that being desirable 1/3 of the time.
>
> The rest of the time, a fresh start makes more sense.
> For many activities, I almost can't imagine ever wanting
> to restart. (Calculator, Connect...)

Indeed, there are edge cases.  Not every activity fits the model as
well as the next.  Still, with the current system, there are some
instances where the above activities could be resumed to good effect.
For instance, the calculator keeps an equation history.  It's possible
that those results would be useful to review again later.  It could
even be the homework.  You know the "show your work" idea that we've
been fed countless times?  Well, if you just turn in your "calculator
session" then it's all right there.  As for games, Perhaps you and I
started a game of connect, and didn't get a chance to finish.  Maybe I
have another connect game in progress with my sister at home.  Each
session stores the game state.  (This example is a bit contrived with
Connect, but consider Chess or some more lengthy games.)

Here is another interesting idea, though, that may be of use.  I agree
with the statement that, sometimes, there are things we just DON'T
care to keep.  Perhaps we should add a secondary option under "Stop"
that offers "Stop and erase," so that you can rid yourself of the
"spam" that would have been auto-saved otherwise.  I still think that
saving by default is a good idea, but offering a way around this for
those instances when you open a calculator to type in one quick
equation (for example) wouldn't be a bad thing.

We'd have to think that idea through a bit more, taking versioning
into account, to be sure that it's feasible.

- Eben