[sugar] re Journal Requirements and preparing kids (was something else)
Sat Oct 11 07:32:30 EDT 2008
On Thu, Oct 9, 2008 at 4:00 PM, Greg Smith <gregsmitholpc at gmail.com> wrote:
> Hi Tomeu,
> Thanks for asking. The product manager role is only meaningful if
> developers and users feel they benefit from it :-)
> A note on my perspective. So far I have been able to focus exclusively
> on XO + Sugar Software. I don't think much about other OSes on XO (e.g.
> Fedora or Windows) or Sugar/XO software on on other HW or OSes. Its all
> 8.2, 9.1 etc for me, so far.
> Two points:
> 1 - On your question of preparing kids for using computers, that has
> come up. It's usually in the context of the need for Windows. That is,
> many decision makers seem to think that learning to use Windows is an
> important skill to prepare people for jobs which use computers.
> We can try to dissuade them by pointing to Linux as the future or
> explaining that understanding computers is the central idea and
> transferable to any OS (no matter how abstracted the processes and file
> system :-). The main idea that the purpose of XOs is to teach kids about
> computers is something I think many on this list ascribe to. Others
> (e.g. me) look at XOs as more of a tool to learn whatever the kids want
> to learn, be it computers or animal husbandry or theology or whatever.
> Most people probably want to see some of both.
> FYI for earlier comment on this, see Design section of this page:
> and my comment on it:
> I'll give one example. I heard of a small country where a trial
> deployment was to be funded by a large corporation. The company uses
> Windows and .Net. One of their goals was to find and train the bright
> kids who would become their future programmers so they were interested
> in Windows. They have other more altruistic goals too so everyone can
> benefit, but it gives you a sense of how this goal of "learning
> computers" is motivated.
Sure, but does the desire of making kids use Windows have anything to
do with Sugar? Can we do anything about it other than making Sugar so
good that people end forgetting about that old software called
> 2 - On the Journal design. I think we are closing in on a rough
> consensus for goals of an updated Journal. The last piece will be the
> hardest but let me see if we have agreement on the first two points.
> a - Journal/datastore must not lose data due to bugs or errors. If the
> user meant to "save", or some part of the OS meant to "save" the data
> must be saved! I think/hope everyone is on board with that one.
Not sure we have on board someone with the gift of infallibility, but
I think we can do much better in terms of robustness.
> b - We should allow access to the file system directly. This is the
> point most adamantly express by John Gilmore (btw there was a round of
> applause by some engineers in the office on reading that one morning
You being the product manager, I hope it's not only to John Gilmore
and engineers who you look for feedback (I guess not, just found
awkward that you only mentioned them as your sources of feedback for
> That is, the Journal should show the full path and file name to
> every file. Should probably show the size and maybe other file
> attributes too.
That's very easy to do.
> The file names should be human readable and accessible
> easily by applications and by terminal commands.
What do you mean by human readable? The user is not being prompted
currently for a file name.
If by applications you mean activities, the current security scheme
isolates them from most of the filesystem, so Rainbow will need to
change before we can provide this item.
Terminal commands (and applications launched from there) are executed
as olpc (thus bypassing Rainbow) and can access all files in $HOME,
that including the datastore.
> It doesn't have to be
> the only way to see files in the GUI but it has to be easily available.
> That is the main way we address the question: "will kids learn to use
> computers by having an XO?" Not sure we have consensus on that but I
> think we are close.
Sorry, didn't get this one, can you expand?
> c - We should allow access to files via other paradigms, tags, search
> tools etc. This is where I think we have the most work to do. I look
> forward to Scott's proposal and more discussion. I said previously that
> I hadn't heard the need for this from the field. Elana and Erik have
> given solid, end user motivated feedback that ~"its hard to find stuff
> in the Journal" so I'm completely on board now.
> Making that better is where I think we can add the most value. Any DOS
> machine in the last 25 years can do the first two. IMHO point c is where
> we can break new ground and lead the industry. Especially if we come up
> with something that really resonates and works for kids and teachers.
> Let's nail down point a and b above as must have, baseline functionality
> for 9.1. Then let's kick around as many ideas for point c as we can
> until we find a clear winner.
TBH, the only features I planned to work on the Journal for 9.1 were:
- more robust, maintainable and faster DS implementation,
- hard linking of files so we don't store identical files several
times (ex. pdf),
- more robust access to USB sticks.
I limited myself to those goals because we have already failed to
deliver on such important aspects for too long, and didn't wanted to
aim for more and fail again as before.
Now seems that OLPC has decided to dedicate some amount of resources
to the Journal + Datastore but I'm still confused about which could be
the best way forward for 9.1. So I would prefer to work instead on
something else that I can trust to be shipped. Can we try to put some
clarity on this issue so we all are on the same page?
More information about the Sugar-devel