[sugar] adding versions to journal/datastore

Greg Smith gregsmitholpc at gmail.com
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 mailing list