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.
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.
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.
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.
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 ;)
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.
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?
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.
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?
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).
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.
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.
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.
We've all heard the problems of children deleting activities by now.
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?").
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.
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 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.
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.
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.
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.
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? :)
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). 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)
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.
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
2. for continual focus and refocus on making Sugar small and smart,
and to focus on making the UI experience really simple
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.
4. for some real classroom environment consideration
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.
Daniel
_______________________________________________
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
