[sugar] adding versions to journal/datastore
Greg Smith
gregsmitholpc
Thu Oct 2 09:55:01 EDT 2008
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.
2 - In terms of better organization of Journal data. It hasn't come up
as a problem from the field in my experience. 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.
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. Even the idea that the newest is at the
top is not universal (see:
http://lists.laptop.org/pipermail/localization/2008-September/001583.html).
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.
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.
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.
Thanks,
Greg S
More information about the Sugar-devel
mailing list