[sugar] notes from the field - Mongolia

Tue Oct 7 14:14:01 EDT 2008

On Mon, Oct 6, 2008 at 6:33 PM, Erik Garrison <erik at laptop.org> wrote:
> On Mon, Oct 06, 2008 at 11:20:04AM -0400, elana langer wrote:
>> Hey Tech Community-
>>
>> I just wanted to give y'all some feedback from my experience in
>> Mongolia. Feel free to contact me with any questions. Please excuse my
>> lay language - it's how i roll.
>>
>> 1) Computers are slow - So I was in a Ger in the west part of Mongolia
>> and I thought I would show the computer to the family that was hosting
>> me. The husband, wife and 8 year old child huddled around the computer
>> and pressed the on button. Instead of being delighted by the computer
>> they waited, and waited for the computer to load. I asked them in
>> broken monoglian to be patient but once the computer loaded they
>> wanted to open an application and again more waiting. The 8 year old
>> lost interest as did the mom and only the man of the house stuck
>> around to try things.
>> This is not a unique experience. This is a culture that lives close to
>> the land. Action- reaction. No one is used to "waiting" for an
>> computer to load or a bagel to toast for that matter. (of course
>> cooking takes time but they can watch as it changes form not just an
>> unmoving screen)
>>
>> In the city the experience is worse. Kids used to PCs quickly grow
>> impatient and leave the XO to find other faster computers.
>
> I think this is very interesting, as I have often heard nearly the
> opposite argument--- that because the XO is often a child's first
> computer their standards for its responsiveness will be as low as we'd
> like them to be.

Where have you heard this? If you have heard it from any Sugar
developer, please cite. If it was a different person, why is this
opinion relevant here? If you heard this so often as you say, you must
be able to cite sources.

> What we have forgotten is that slow technology is, to the uninitiated,
> indistinguishable from broken technology.

I think you meant "no feedback" when you wrote slow. Eben has
acknowledged several times that we lack on this aspect and has
contributed several patches to improve it. Would be very good if you
could devote as well some of your time to this end. I'm sure that Eben
will kindly direct you to places where more feedback is needed.

> How are we going to rectify the general slowness of our user interface?
> It may not be enough to work on the performance problem from within the
> existing framework.  How will we know if this is the case?

First you need to understand why things are slow, then you can start
talking about fixing it. If you start talking before that, then you
waste other peoples' time.

>> 2) Can't save files - this should probably be the first item on my
>> list. It drives teachers and students crazy. They make something in an
>> application, take some pictures or write something and then have to go
>> through a really tough process to find it and save it on an external
>> drive.
>
> My impression is that the journal design stems from a belief that we
> have an opportunity to completely redesign human-computer interaction in
> terms of data storage.  Unfortunately this is simply not the case.
> Teachers have experience with existing systems.

No, the journal design stems from the wish to provide a way to present
the users' work in a better way than existing systems.

I don't really understand why the human being must stick to the
Windows way of organizing files until the sun explodes. Are you
completely sure we cannot improve it?

Everybody can understand that sticking to what people already know has
some value, but we already know many of the problems that arise from
the traditional file managers. These issues are well exposed in this
presentation from Federico Mena Quintero:

http://www.gnome.org/~federico/news-2008-07.html#document-centric-gnome

When one of the founders of the most widely used open source desktop
takes the time to expose these flaws and code a prototype that looks a
lot like our journal, I think we deserve to be treated as something
better than a crazy bunch that just want kids to use the strange stuff
they dreamed of.

There are a set of usability problems with the traditional file
managers and we thought that it was important for OLPC's goals to try
to address them. We haven't had the resources we would have liked (not
even a single person working full time on DataStore+Journal) but I
think that we have seen that the Journal as envisioned provided enough
to our users such that it's worth to keep working towards this end.

Of course, would be easier for us to just say "a folder-based file
manager is all our users deserve", but I don't think we would be being
honest with our goals.

> If they have any
> computing experience (and let us hope they do if they are using
> computers in the classroom!), they have worked with a hierarchical data
> management system which required them to give fully qualified names to
> their work.  In breaking with this paradigm we rob them of this valuable
> expertise and frustrate their work with our system.

As I said above, every little thing you change will frustrate
somebody, should we stop doing stuff and just deploy Windows? Or
should we strive to offer more value so the cost of learning something
new is offset?

>> 3) Basically - The journal is really hard for people/ kids to use over
>> a longer period of time. Kids and teachers can't find things that they
>> did unless it was done within the last 30 minutes.

I'd like to know more about the difficulties that were observed. Also
would like to know how storing all files in "My Documents" and/or the
desktop is better than the journal. Or how ordering files inside
folders is easier that adding a tag to an entry.

> This effect, brought about by the user interface of the journal, is
> exactly the opposite of its most fundamental design principle: don't
> lose user data.
>
> In my mind the fundamental problem is that users aren't required to
> fully qualify names for their work.  Doing so seems to lie outside of
> one of the core points of Sugar's design ("There are no files, folders,
> or applications." -- http://sugarlabs.org/go/Main_Page).

I fail to see how by requiring that users give "fully qualify names"
to their documents is going to help here. In my experience, paths
don't help users because they don't remember the exact path they gave.
Now, if you had search...

> Is it
> conceivable that we could change this feature of the system in future
> releases to clarify data management on Sugar-running XOs?

Please explain what you mean by "change this feature". And please
don't be so vague and purely negative. We have lots of work to do and
if I have to read and reply so many emails from you, I really need you
to be more rigorous. I just don't have the time to guess what is
behind your words nor get into abstract discussions when we have very
concrete problems. If you think something should be changed, please
provide an alternative better than what we currently have.

Thanks,

Tomeu