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

> Measure should also be able to open audio files
> from elsewhere. (and inefficient stuff like CSV too)
> Think about looking at sounds from Record or TamTam
> in Measure, or playing sounds from Measure elsewhere.

That could be nice.  I like the idea that things interoperate as much
as possible.

> > > 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.
>
> That isn't small unless you waste it. Waste would be
> using XML, using CSV, using wordprocessing formats
> when you only need plain text, spamming the journal,
> and so on.
>
> Don't you remember using computers with far less
> than a gigabyte of storage? Not even counting the
> stuff prior to the graphical internet and high-resolution
> screens, I had at least 3 operating systems installed
> in 1.6 gigabytes back around 1996. One of those was
> NT, and one of those included multiple copies of the
> Linux kernel source. I kept that setup for years.
> It worked very well.

I know that it can be done.  But I also know that storage capacities
kept doubling quickly, and that no matter what size they were, they
were always getting filled up.  I had a single college project that
required a dedicated 250 GB hard drive.  That's an exceptional case,
for sure, but offering these kids lots of rich media tools is going to
use space if we like it or not, especially given their projected 5
year lifespan.

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

Also, what do you mean by "delete the old data and restore default
settings?"  This is precisely what we're trying to prevent having to
do.  If you want a new file, then you create one as in your first
"Fresh" example, but otherwise resuming should be the norm.  We need
to make the resuming experience a better one to be sure that this is a
preferred approach.

Oh, and not yet implemented, but planned is an option like:  Hit frame
button, select "Show recent" from the activity palette (to dive into a
pre-filtered Journal), and click to resume the entry you wanted.

- Eben