[Sugar-devel] Deployment feedback braindump

[Tomeu Vizoso]

Hi,

some thoughts follow. Please keep in mind that these are just my
personal opinions and that not everybody at Sugar Labs share the same
idea of what SLs is or should be.

On Sun, Aug 9, 2009 at 19:41, Daniel Drake<dsd at laptop.org> wrote:
> Hi,
>
> In response to the thread I started recently about feedback from
> deployments, I've been thinking a lot about specific changes/features
> that would be a big help for deployments.
>
> And even though it only takes 10 minutes in a classroom to see some
> real potential areas for improvement, actually I am finding the task
> of selecting a few important features/bugs/changes very difficult, and
> I keep coming back to various broad questions and loose ideas about
> Sugar's direction, goals, and SugarLabs' roles.

It's great that you are sharing your thoughts on this, hope others
will do the same. I'm cc'ing IAEP because this isn't really technical.

> So I'm afraid that I'm creating another vague, broad and fluffy
> discussion without any real immediate technically actionable items,
> but I'm going to try and put my thoughts into writing anyway.
> Suggestions on how to make some of these ideas actionable would be
> appreciated. I fully understand that nobody can really define Sugar's
> direction at the moment since it's all volunteer time, but hopefully
> we can at least get some objective things written down which will
> possibly feed the motivation of our valued hackers.

And not only hackers, but most of Sugar Labs. Those already working on
a deployment have probably little energy left to consider other
deployments' needs, but all the rest of the community will be sensible
to the needs of the deployments that care to communicate their needs.

> I'll start with roles. Sugar was born inside the belly of OLPC, and
> SugarLabs was born out of OLPC, effectively taking some roles of OLPC
> and further opening them to a community. So, in terms of roles, you
> might look at this as OLPC being top of the food chain (I'm referring
> to the times when OLPC had a substantially larger technical team),
> with SugarLabs below doing some specific subset of OLPC's earlier work
> (i.e. developing the UI), and finally deployments below being the
> consumers.

I'm not sure I agree with that. I see Sugar Labs as a _place_ where
everybody interested in improving learning with Sugar can meet,
communicate and work together. As far as I know OLPC has never aimed
to be a place, but rather an agent. Who may be taking responsibilities
from OLPC are other agents such as OLE Nepal and individual
volunteers, who happen to use Sugar Labs to work together.

> But actually I think it makes sense for this model to be considered
> differently, as follows: SugarLabs is the top of the chain, it is the
> upstream that generates the core user experience.  One step down, OLPC
> as an implementation specialist (again referring to the time when the
> development team was more substantial) takes Sugar from upstream,
> makes some small customizations to fit the OLPC mission, and fills in
> some big gaps of OS development and support, deployability and
> scalability, distribution, hardware work and software to support such
> hardware, user support, etc. Then the deployments feed directly from
> OLPC, not sugarlabs. In this model, OLPC performs a huge chunk of
> support for sugar's users.

This makes sense, we are also seeing several other organizations
playing that role, but it's also true as you point below that some SLs
members prefer to carry these activities as part of Sugar Labs rather
than on their own organizations. I hope that this is temporary and
that as their deployment activities scale up we'll see new
organizations getting formed and their relationship with Sugar Labs
formalized as local labs.

> I think this model was working reasonably well (and was improving over
> time) but the middle layer (OLPC) has now changed to the point where
> it is not performing many of the roles mentioned above, or at least
> not in much capacity.  So who can take over this work? It is certainly
> very important. My gut feeling is that SugarLabs should - but that
> really is only because (1) a number of the OLPC people who would be
> involved in the above roles are no longer OLPC people, but they are
> still sugarlabs contributors, and (2) there are no other good
> candidate parties that I can think of, so I naturally have desires
> that the one that I do know of pick up the work ;)

Don't think we should see in Sugar Labs more than there really is.
It's true that we have a rather broad mission, so most of what can be
done with Sugar has a place in SLs, but that broadness of mission also
means that we (as a single organization) don't have enough focus to
solve every issue that real users find.

The broadness of our mission means that everybody who wants to use
Sugar for learning has a place in SLs, but that doesn't mean that SLs
itself is going to take care of everything. Rather, it means that
people who want to use Sugar in their communities should get their
organization formed in the way that best serves them, get their own
resources and use SLs as a catalyst so that their efforts bring them
much bigger benefits.

> These might not be considered good reasons, but it seems that
> sugarlabs was "designed" with the consideration of having OLPC
> performing a great deal of support on its behalf, and I don't recall
> seeing any proposed change of SugarLabs' direction in response to
> OLPC's recent restructuring.

Well, I tried to stop sleeping after OLPC's restructuring, but it
didn't worked too well, so I had to go back sleeping 8 hours per
night.

Seriously now, it's unfortunate that OLPC has no resources to invest
in Sugar any more, but it doesn't mean that SLs will have to do some
magic and hire a team of developers to substitute them. We are a
volunteer-based organization, and I don't think we can replace OLPC.

OLPC's customers are spending millions around Sugar but their
involvement in Sugar Labs is in most cases zero. If you want to see
more OLPC-related work in Sugar Labs, then you can look at there for
resources.

And OLPC itself would be benefited if their customers worked together
in Sugar Labs instead of separately duplicating their failures.

We have very good examples to follow in OLE Nepal and Paraguay Educa,
but they represent a very small part of total OLPC deployments.

> I've only written about OLPC so far, although it's clear that
> SugarLabs is aimed at a broader audience. And in persuit of these
> efforts, SugarLabs has started muddying the waters by taking on (in
> small scale) some of OLPC's prior roles -- namely becoming a OS
> builder (e.g. SoaS) and a deployment implementer (e.g. GPA). Sometimes
> I even see hints of broadening even further, for example, in a SoaS
> meeting recently I saw some interest in SugarLabs becoming involved in
> improving Linux support for hardware chipsets -- a problem that half
> the friggin' world is already working on.
>
> So: which roles is SugarLabs trying to fill?

I hope what I said above about SLs being more a place than an agent
clarifies this.

> Although I know that SugarLabs is trying hard to broaden beyond OLPC
> deployments, I'm going to throw in a couple more comments along
> OLPC-specific lines anyway: if SugarLabs is going to continue to be a
> deployment implementer, i.e. doing anything and everything required to
> make places like GPA "work," then I would encourage the interested
> people to not forget about OLPC deployments. With a bit of
> determination, it is possible to get yourself to these places. And
> with a reduction of support from OLPC themselves, they would really
> benefit from your help. Unlike most new Sugar deployments they have
> often already solved various problems related to logistics, finance,
> politics and scale, so you could focus directly on the Sugar
> experience.

I would personally love to visit those places and see my work being
used by someone, but then, who would maintain the software they use? I
have a personal goal of passing maintenance to other people, but that
will take some time, see my email past week about code review and
maintainers needed.

> The next item that keeps coming up in my thoughts is that of aims and
> objectives for the platform, in a technical sense. OLPC still has a
> set of 5 clear principles that have stuck from early on, and have
> really really really taken root at deployments. I was always impressed
> with OLPC's focus on considering the scalability of any new technology
> entering the platform (i.e. we're going to be replicating this A LOT -
> will it work in numbers?), as well as its appropriateness in
> remote/unconnected parts of the world. Making things really really
> simple also came up a lot during my time there, given the 6-12 year
> target age range -- a range that was frequently brought up in
> discussions. There was also the trait of making things small and
> elegant, to be efficient with things like power and also to run well
> on low-spec hardware. Anyone remember the goal of a 100mb OS?
>
> At least from what I have seen, this kind of clarity seems to be
> missing from discussions that define the Sugar platform nowadays, as
> well as in the code that is flowing through the system. Does SugarLabs
> still have a high degree of interest in bigger-than-you-can-believe
> deployments in remote and really difficult parts of the world on
> low-spec hardware, or are we moving towards looking at occasional
> 30-student deployments on powerful computers in schools along the
> Charles? Or are we trying to do both?
> Are we still focusing on 6-12 year olds or has that changed?

How do you expect that the SLs volunteers know what OLPC deployments
need if they don't voice their needs? If you look at the Sugar commit
logs, you will see that almost all commits are from someone sitting in
a room somewhere in Europe, working on their free time. By which kind
of epiphany do you expect them to know what's best for OLPC
deployments?

I often feel placed between a rock and a hard place when I voice such
concerns about a patch or proposed feature. My reputation lessens
every time I say that I won't accept some work because goes against an
OLPC-related goal and nobody directly involved in OLPC backs my words.

> Another recurring question is how much work we can expect deployments
> to do. In an ideal world, SugarLabs could be an upstream developer,
> and the deployers could do all of the deployment-related tasks.  Clean
> separation.
>
> However I can see 2 painful realities of that model. Firstly, even
> though deployments and their requirements always differ substantially,
> there would still be a huge amount of duplication of effort around the
> world. It makes sense for there to be a "deployment technology
> upstream" in the same way that we aren't asking each deployment to
> write their own UI and applications - we have a development upstream
> for that (SugarLabs).
>
> Secondly, this just won't work for deployments in general. Deployments
> are really difficult. You don't have enough people, so everyone is
> overworked. In many of these places it is really difficult to find
> people with the required computing skillsets, and even if they exist
> they aren't likely to accept the piddly salary offered by your
> cash-strapped NGO or govt organisation. Or you might be lucky enough
> to find one or two people, but they might take advantage of their
> skills and get a scholarship to go and get a better degree in a richer
> country. By requiring deployments to do technical work, you're
> *really* challenging them (and sometimes, excluding them).

We have volunteers working on deployment issues so deployments
themselves don't need to do it. You say that's not enough, how can we
get more resources?

> Another way to look at this: if SugarLabs could take steps to make
> deployments easier, then the world of potential deployers will grow
> dramatically, and existing deployments will have more time and
> resources to spend elsewhere.

This is the mission of our deployment team. But nobody related to OLPC
deployments have joined it:

http://wiki.sugarlabs.org/go/Deployment_Team/Contacts

> If we dream a little more we could even add some reversion of the
> roles into the picture - selected staffers from deployments could even
> become integral parts of SugarLabs. But I simply don't see that
> happening except in exceptional cases.

The thing is that I can see someone getting resources to deploy
laptops for education, but I don't see who will give us resources to
support those that deploy laptops. Even less if those supposed
beneficiaries don't know that we exist or aren't interested in working
inside SLs.

The problem you point out has been present in our minds since day zero
of the local labs concept. We have the organizational structure to
pool resources, it's just that people either don't know us or prefer
to work alone.

http://wiki.sugarlabs.org/go/Local_Labs

If deployments really want to work together with others so they can
reduce their technical expenses, we have an structure they can use and
we'll also continue to do what we can as a volunteer-run organization.

> Now moving onto some things more directly related to deployment
> experience. As I stated in my questions above, I'm not sure, but I'm
> really hoping that sugar is just as dedicated as it always was to
> provide a really really simple UI for 6 year old children. Everything
> is so much harder in a classroom, and every small problem encountered
> causes significant disruption. A teacher here in Nepal expressed some
> discontent in using laptops during class time, due to the amount of
> time and effort needed to go around and get everyone on the same
> screen etc.
> How about the first boot experience - typing in your name and choosing
> colours? This is seriously challenging for our users. I remember in
> one higher-grade class in Ethiopia, we drew the screens on the
> blackboard and explained what to do. To illustrate even more, I wrote
> my name inside the "Name:" box that we had illustrated on the
> blackboard.
> Then, walking around the room, we saw that many people had written
> "Daniel" into the name box, and also did not know what to do next
> (they had not picked up the instruction to click 'Next'). Granted
> these are young children and first-time users, and I don't mean to
> look down upon the skills of these children, but still I hope that
> this gives some insight into the kind of user-level profiency that we
> deal with in the field.

It's not clear to me that you think we can do something to improve the
first boot screen. If so, please enter a ticket.

About the generic problem, I see how it can be hard to guide such
students from the blackboard. Already considered teaching first a
small group of students and have them teach the others?

> We've all heard the problems of children deleting activities by now.

We have a proposed change, would be nice if someone from a deployment
validated that it's good enough before it gets implemented:

http://dev.sugarlabs.org/ticket/1128

> I've also seen kids click the "disable wireless" box and then wonder
> why they can't get online. I think that this highlights 2 things --
> firstly, that kids make erratic mouse movements and sometimes click on
> things without realising. Secondly, most options/questions that sugar
> presents will simply elicit random responses from the users, even if
> we think we have communicated the message as clearly as possible ("Are
> you sure you want to erase this activity?").

We have known from the start that we are not going to nail down the
best UI at the first try, no matter how brilliant are the user
experience designers we have. But we had to start with something so
people could give feedback. Now we need to get that feedback and make
sure it ends up in technical actions. Who wants to work to make it
happen?

> Through my experiences I believe that things even as simple as
> connecting to networks and registration to the school server is
> sufficiently complicated to cause real challenges in the classroom.
> And the consequences of failing to do this properly can be painful
> too. Moreover, this could all be automated.

Agreed, let's work towards that, but remember that one size won't fit
all, so we'll have to let deployments swap or disable those
algorithms.

> Simplifying the user experience is *key* -- sugar has already taken
> many leaps in this area, let's keep this as a high priority, and make
> sure that this is communicated.

I feel often alone when someone proposes a new feature and I warn
against cluttering the UI. If deployments feel that clarity is an
important characteristic of our UI, I would like them to support this
position when we discuss new features. Same about UI consistency,
another aspect that an activity author sitting in her basement may not
be able to realize its importance in the field.

> I look at some of the new sugar features (e.g. buddy tagging) and am a
> little doubtful if they will be used except by older children who have
> become exceptionally proficient at using the computers.

That's an interesting statement, do you think we are grossly
overestimating the capacity of our users?

Should we offer features like buddy tagging that aren't _required_ for
basic usage and that may only be discovered by a fraction of our
users?

> Another thing that hits me from my classroom experiences is simply how
> far away Sugar is from world-standard classroom practices. For
> example, how would Sugar satisfy the following:
>  1. Teacher presents lesson material to all children
>  2. Teacher provides or stimulates some kind of exercise
>  3. Children do the exercise
>  4. Children submit their work to the teacher
>  5. Teacher evaluates the work
>  6. Based on the evaluation, teacher provides feedback (e.g marks) to
> the children (often on a 1:1 basis)
>
> Sometimes, steps 3-6 are repeated several times until the child has
> produced satisfactory work or corrected all mistakes.
>
> Sugar's collaboration model just doesn't cut it for that process at
> the moment. If you are able to get it to somehow model the above, it
> just doesn't feel right, and it is not a smooth experience. Or it just
> ends up taking a lot more time than it is worth.

Do you have an idea already of what would work?

> A similar point which Christoph raised to me the other day -- at these
> ages, when you do good work in primary school you got small rewards
> like stickers. Sugar has no equivalent of this, but yet this is quite
> valuable in a school setting. It definitely made a difference for me,
> I can even remember a specific time when I received a sticker from
> *the headmaster* for a piece of work I did about the carribean islands
> (and I must have been 7 or 8 years old at the time). It obviously made
> an impact on me as I can remember it so clearly.

Yes, we discussed it in the Paris SugarCamp and some people shown
interest in pursuing it. But again, we have the resources we have.

> Another common classroom practice -- working from textbooks where
> there is some content on the page and you fill in the rest. No real
> equivalent in Sugar. Maybe we could do it with Moodle, but Sugar's
> integration with moodle is really minimal (and without tight
> integration, the user experience is sufficiently complicated to make
> it unrealistic for use in a classroom). Maybe we can do it with eToys,
> and actually they even did this in Nepal for a while. Squeak
> programmers were hard to come by, but they found a few. They produced
> excellent interactive learning materials. But due to the calibre of
> person who is a Squeak programmer, time and time again those people
> would find life-valuable opportunities (e.g. to go and study at MIT)
> and would leave the organisation. After this happened a few times, OLE
> Nepal converted to writing all activities in flash in order to be able
> to engage a wider range of content developers. The point is that
> sometimes, providing the technology is not enough - there are other
> things to consider before it becomes deployment-ready.

Do you think Sugar itself should provide something in this direction?
Or could be instead an activity in the same spirit as Memorize, that
can be used to create lessons?

> Sugar doesn't even do that well on the step below that -- static
> books. Ones that don't move and don't get written in, which should be
> a much easier technical problem to solve. At the time of deploying
> OLPC OS 8.1 in Ethiopia, the process of opening a PDF from a library
> bundle involved so many clicks (open Browse, click books, click your
> grade, click the textbook you want, click Show in journal, click
> Resume) that we had to write a page of instructions (including
> screenshots) on how to open textbooks. And even that wasn't a great
> solution, because children started clicking on the buttons on the
> screenshots rather than the buttons on the sugar UI! Also, the loading
> time was pretty horrendous and every time you opened the textbook, a
> new copy of it would be saved in the journal (bye bye disk space).
> Granted, the latest Browse bundle for sugar-0.82 includes a creative
> collection of hacks to solve some of this, but this is not present in
> sugar-0.84 and was never a real solution anyway. (or did we decide to
> replace the sugar shell with the browse activity? :)

I added duplicated file detection to the 0.84 DS because of this.

> Also, the process of bundling up the textbooks is pretty challenging
> for everyone except us. Creating library bundles needs to be made
> easier. At the most simplistic level, Sugar could treat a zip file of
> PDF files as a library bundle and produce some kind of index screen
> allowing you to open them in Read (removing the need for specific
> directory structures, human-unintuitive library.info formats, having
> to create a HTML index, requiring the user to open the Internet
> browser to open a local resource, etc).

We have had some discussions, but AFAIK we need more work until we get
a design that can be implemented. Would be nice if OLPC deployments
facing this problem considered participating in these discussions.

> Sugar currently doesn't even
> have support for the library bundle technology which was adopted by
> various sugar deployments, as it doesn't have a way of accessing the
> index.html pages short of typing in the file path in Browse. (the
> functionality of olpc-library needs to become part of the sugar
> platform, in some form)

You mean that you cannot open that library bundle by clicking on its
journal entry?

> Sugar is obviously geared to constructionist learning which is
> generally carried out differently from normal learning using books,
> but the fact is that you can't just walk into classrooms with this
> mentality. The way to do it is to provide the tools to simplify what
> the teachers have to do already (it's their job), that way you then
> have time for other activities which you might define as being "pure
> constructionist." That said, one thing I have learned in Nepal is that
> thinking about books, exercise books and the curriculum doesn't have
> to be boring -- their strictly-curriculum-based learning activities
> here are both engaging and can foster creativity. Also, there are
> other opportunities to go halfway, for example adding an interactivity
> component that would be impossible to have when working with
> paper-based exercise books.

I don't think you need to be worried about SLs contributors only
wanting to do "constructivist" things. If a deployment markets
correctly their needs and gets people excited, I'm sure you will see
people volunteering.

> So I guess my wishlist from this email would be these items:
>  1. for SugarLabs' aims to become as clear as OLPC's 5 principles

Why is the current mission statement not clear?

http://wiki.sugarlabs.org/go/Sugar_Labs

>  2. for continual focus and refocus on making Sugar small and smart,
> and to focus on making the UI experience really simple

This won't happen if the people that feel this need don't voice their
position in our discussions. Please help us. Ben did his part when we
discussed Qt, we need more like that.

>  3. for people to support OLPC deployments in the same ways that we
> are seeing people doing support-work-outside-the-UI for SoaS/GPA etc.

Again the same. Caroline is doing an awesome work expressing her needs
and an enormous effort learning to work with everybody involved. Why
aren't doing the same other Sugar deployers?

>  4. for some real classroom environment consideration

I bet OLE Nepal has accumulated lots of knowledge on that and I hope
we can get to something actionable.

> I am going to list myself as a candidate for the sugarlabs oversight
> board with this email as a reflection of my way of thinking. I plan to
> be involved with deployments for the next 12 months and I hope I'll be
> able to encourage action along these lines.

Excellent news, I'll vote for you.

Thanks,

Tomeu

> Daniel
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>