[sugar] adding versions to journal/datastore

[Tomeu Vizoso]

On Thu, Oct 2, 2008 at 3:55 PM, Greg Smith <gregsmitholpc at gmail.com> wrote:
> Hi Guys,
>
> This is a great discussion and very helpful design interaction!
>
> Just sampling a few items on this thread I have two high level comments:
>
> 1 - The primary requirement for the Journal is to never lose data. I
> think there are some known issues with the datastore but I'm not sure
> where they are tracked. The most important case is to not lose data when
> the users exits the activity or keeps. The secondary case is to do
> interim saves so that if the XO or activity crashes or the XO is shut
> down we still save something recent.
>
> Please don't try to extend the Journal paradigm until we nail, provably
> and completely.

Well, precisely the proposed addition is for stopping losing so much data ;)

We are currently overwriting lots of potentially useful work, the
proposed scheme tries to minimize the lost data without taking up too
much space or making the journal more cumbersome to use.

> 2 - In terms of better organization of Journal data. It hasn't come up
> as a problem from the field in my experience.

Erik and Elana have said that they have heard of severe difficulties
to find stuff in the journal, to the point of saying that data is
effectively lost because of this. We haven't managed to get concrete
issues from that feedback yet, perhaps you could take up that task and
give something more actionable to developers?

That said, versions have little to do with this issue.

> It can still be improved
> and making it easier to optimize the available storage seems like a high
> priority based on NAND full issues. We should still consider better data
> organization and access, especially if we can make something that really
> resonates with kids. We especially need to address saving and accessing
> in the collaborative creation process.

Agreed, but this doesn't have much to do with versions, does it?

> The concern I have with the discussion so far is that its way too
> complicated. I don't think any K - 6 grade kid will have a good
> conception of a "tree" or hierarchy. It will be incomprehensible and
> work like black magic to them.

No tree or hierarchy will be exposed in the UI. We just leave around
more intermediate entries and make accessible in a popup a list of
older versions of an entry.

> Even the idea that the newest is at the
> top is not universal (see:
> http://lists.laptop.org/pipermail/localization/2008-September/001583.html).

I can agree with that, but we need to put them somewhere ;)

> The notion of "size" or quantity is not the same for a kid as an adult
> either. One Piaget experiment I read about showed that most kids below a
> certain age would assume that 5 items spread far apart were more than 6
> items placed close together. Throw in many items of the same screen
> space each with a different size in MBs and they will completely miss
> that one quantity is more than the other.

How can we change the UI to better acknowledge this fact?

> I don't mean to make this impossible to design. I suggest that we make
> sure we nail the reliability piece first. Then come up with some
> experiments which cover use cases and include mock-ups. Then test them
> with kids. If we design this based on our own understanding of what
> works for us, we can make something useful and interesting but it may
> not be optimized for kids. Optimizing for the ways kid's minds work is
> something we can do better than anyone else, if we can get good at it.

I don't think that we have current plans to change the Journal UI
substantially in the next release. But if we had well-focused
feedback, we may be able to suggest UI changes that improve the user
experience.

> My 2 cents. I apologize for being such a skeptic. Lately I feel like I'm
> swimming up stream. If the river is flowing towards consensus and we can
> make something short term which we can learn from, don't let me slow you
> down.

I don't think it's time to be nor skeptic nor the opposite. We should
instead work now on finding clear links between issues on the user
side and work to do during the next release. That's how we'll be able
to most effectively use the existing resources.

And just for the record, I'm ok with not doing versions for 0.84, but
I do think we should move forward on the discussions now.

Regards,

Tomeu