The tedium of erasing journal entries

[Eben Eliason]

A conglomeration of responses follow...

Also, as a prologue, I will refer occasionally to the designs on the
wiki [1], and in particular the 6th slide [2] with respect to the
"deletion issue".  It's also prudent to note the initial description
of the Journal [3] which remains, in nearly all respects, our target.

Oh, and please don't be intimidated by the length; there's a really
important chunk at the end...

[1] http://wiki.laptop.org/go/Designs
[2] http://wiki.laptop.org/go/Designs/Journal#06
[3] http://wiki.laptop.org/go/OLPC_Human_Interface_Guidelines/The_Laptop_Experience/The_Journal

On Sun, Aug 3, 2008 at 3:38 PM, Aaron Konstam <akonstam at sbcglobal.net> wrote:
> Unless I have missed something that is a very tedious task to lay on
> someone using the current GUI interface for erasing journal entries.
> Journal entries are added at a steady rate but their removal is a
> tedious "one at a time process". I can't imagine child taking the time
> to keep these entries erased routinely. Another erasure method is
> needed.

Wholly agreed.  The new Journal design offers checkboxes next to each
entry, allowing for multiple selections to be made.  Once made, it
will also be possible to filter only to selected entries (in case the
selection should span large portions of the Journal and be otherwise
impossible to view at once), and then act on those entries en masse
via a contextual toolbar, in order to delete them, copy them to
external storage, or tag them.


On Sun, Aug 3, 2008 at 5:29 PM, Bastien <bastienguerry at googlemail.com> wrote:
>
> In latest joyrides, is there a way to "select all" entries?  (C-a)
>
> This would be useful not only for deleting, but also for copying entries
> on the clipboard or on the USB key.

There is no select all at present, but once we have the checkbox
mechanism described above, I could see this shortcut checking all
entries.  However, I think that such an action will actually be an
edge case once we get everything else right, since copying/deleting
every single entry at once probably won't be that common.


On Sun, Aug 3, 2008 at 6:03 PM, Albert Cahalan <acahalan at gmail.com> wrote:
> I don't even want to look in the journal. Not ever! It's unusable.
> It's worse than the worst email inbox nightmare. Nothing has a useful

This is something we hope to partially remedy in a future release.
Naming clearly took a backseat, in part because it was more important
to offer an activity supplied toolbar when opening activity, in part
because we don't prompt for a name, and in part due to the journaling
auto-save nature of the system.  We intend to add a either a) a
non-modal alert upon creation of a new instance from scratch (never
when resumed), which can be ignored if desired, which prompts for a
name (and tags?) or b) a modal alert upon stopping an activity which
prompts for name and tags (only if it hasn't been named before).

Optionally, the latter could also have an explicit "don't keep"
option; this has been hotly debated, but there could be times when
it's appropriate to have.

> name, the scroll bar doesn't move with my mouse, clicking to mark an

Indeed, this sucks.  We know it.  We want to fix this, and make clean
pixel-by-pixel scrolling of entries.  This is a really big project
(Well, the entire redesign of the Journal is), and it's one we all
would like to see happen, but resources haven't yet allowed it.

> entry takes many seconds to work (leading me to click again), and

This is a known bug.  A re-factoring of the Journal GUI code is
needed.  It's not terribly difficult, but it is invasive, so it wasn't
slated for the 8.2.0 release.  I agree it's a problem, and I tried
myself to fix it before realizing how entangled it is.  Note that the
star buttons in the list view of Home don't share this problem.

> the purely iconic interface is totally incomprehensible. I'd even
> prefer the dreadful interface of Macintosh System 1.

Well, first I disagree that it's entirely incomprehensible.  However,
I admit that it could be better.  Please refer to the new designs on
the wiki, which illustrate a much more friendly approach to looking at
recent entries, which includes expandable entries with inline previews
of the in-progress activities.  We hope that this will make browsing
the Journal much much friendlier, without the need to dig into detail
view all the time just to figure out which entry is which.


On Sun, Aug 3, 2008 at 7:55 PM, Gary C Martin <gary at garycmartin.com> wrote:
> I find my way around my 900+ entries just fine. I do agree that a high
> percentage of my entries seem to be cruft, but there is a proposed UI
> feature that I believe will greatly reduce accidently creating new
> journal entries when what was really intended was a resumption of an
> earlier entry. The much needed extension of the new Home view to
> default to, and display, recent entries for said activity.
>
>        http://wiki.laptop.org/go/Image:Activity_management-07.jpeg
>
> This combined with a larger Activity name input box (ridiculous small

Agreed.  There's no excuse.

> for no good reason I can fathom), and perhaps even a dialogue to
> prompt for a name if one is not set when stopping (though this may
> well be annoying unless well planned - a good default name, auto

We argued it both ways a few times, which stalled the progress a bit.
I lean toward a non-modal alert on creation of a new instance (which
can be ignored; would go away after 10 seconds or so).  We could have
a modal alert on close, which requires one to interact before it goes
away.  There are pros and cons to both.  We could actually do both, as
well, and the latter could also have the "don't keep" button on top of
that.  There are options.  We should nail it down for 9.1 and get it
done.

Pros for non-modal: Can be ignored, names activity before sharing,
which gives it meaningful name in Neighborhood
Cons for non-modal: Might not know what you're making yet (though, I'd
argue, possibility to ignore mitigates this)
Pros for modal: Comes at the end, when you know what you've made,
could offer a "don't keep" option
Cons for modal: Can't be ignored, doesn't name things before sharing

> confirm timer, input focus for typing, return key for immediate
> acceptance etc).

Yes to all of these, regardless of which we choose.

>> Clearly, nobody is dogfooding.

True and false.  We definitely all use XOs a lot.  We also use them
enough to know their limitations, and to know that for many of us, day
to day use for all of our tasks simply isn't practical (yet!).  While
it's a noble goal, it would also slow us down, even though we're
already a team spread thin and with timelines that are near
impossible.  In other words, we're not ignorant of the problems; I
think the Journal is mostly unusable right now too.  We acknowledge
the deficiencies, and are working hard to fix them.  Your constructive
feedback and criticism is certainly appreciated.


On Sun, Aug 3, 2008 at 11:00 PM, Bastien <bastienguerry at googlemail.com> wrote:
> There could be a default (favorite) filter for the journal entries.
> I'd suggest something based on time: the more recent the entry, the
> more likely it's you want to resume it.
>
> Such a notion would also nicely combine with the notion of favs in
> the home view.  And maybe it's not that hard to implement?

We do have the star (favorite) buttons in the Journal. Unfortunately,
they are just for show at the moment.  The new designs aim to make
them meaningful.  There will be a way to filter to show only starred
items, which will do a lot for the "spamming" problem in itself.  It
should reduce the large number of entries down to those that are
specifically useful or meaningful to the laptop's owner, allowing them
to search and browse through a subset of all available entries.

<important> <!-- This chunk is an extremely relevant portion of my
response to the initial problem posed; please read -->

Favorites will also be used as a primary heuristic for the forthcoming
"auto-deletion" mechanism.  Before anyone gets up in arms here, note
that I place that term in quotes because we don't actually anticipate
deleting anyone's data behind their backs.  Instead, we want to
support a system which -- based on factors such as favorites,
knowledge of current backups, frequency of use, recency of use, file
size, intermediate versions, whether or not entries have been
named/tagged, etc. -- periodically (when the NAND starts to fill up)
/suggests/ to the user a subset of the Journal which could be "safely"
erased without much loss.

The children (or teachers, or you) then have the opportunity to review
the suggestions, uncheck (or favorite) some that they think they
really do want to keep, and then press a button to get rid of the
rest, cleaning out the "cruft" so to speak.  I'd like to think of them
more as experiments than "cruft", but oh well.  The point is, the
Journal should make management simple, and for that matter, one could
simply place trust in the Journal eventually, and simply confirm the
cleanup operation without second thought.  The intention, of course,
is that the backups should make most (if not all) of these entries
recoverable later.

This system is meant to work in tandem with our natural ability to
remember (or forget), cleaning out old and less meaningful entries
over time, just as we forget about them over time.  The human
interaction required for the cleanup step can also serve as one last
look through the boxes which have sat for too long in a box unlooked
at; a time of retrospect, of reviewing progress, etc.  I think this
will be a natural process of using the laptops, and the Journal, in
the future.  These boxes then get sent to the attic (the backup), and
perhaps eventually, we'll also need a way to clean out the attic and
permanently toss things.  We'll get there.

</important>


Thanks for all of your comments, and for reading through my rather
lengthy responses.

- Eben