I hope I have made myself clear. The future of Sugar Labs, if it has
any, is to provide Sugar on all widely distributed platforms so that it
becomes a viable option for potential adopters. Sugar Labs needs to
understand that a parent or educator who is looking for an educational
platform is not going to build a development environment and demonstrate
their knowledge of PRs by fixing random bugs or install a Fedora desktop
to generate an SOAS stick.
Sugar Labs needs to release 0.110 for easy installation on PCs,
Raspberry Pi, and Windows 10. It then needs to document 'Get Sugar' on
the Sugar Labs website for non-technical computer users. It needs to
re-focus on the goal to provide a constructionist learning environment
for primary school children. None of this requires an academic analysis
suitable for an MBA dissertation.
Naturally, Sugar Labs needs to continue to work with James Cameron to
provide viable software for the XO. We must thank Lionel Laske every day
for understanding this issue and developing Sugarizer to provide some of
Sugar's capabilities to the huge installed base of mobile devices which
do not support Python.
I think we need to remember the mission of OLPC/Sugar - to provide a
better learning opportunity to children on the wrong side of the digital
gap. Our hope should be that wide availability of Sugar on PCs and
Raspberry Pis will make it a viable alternative for installation in the
deployments served by Computers for Kids, Rachel, and others where there
is no internet availability, no prior computer experience for either
teachers or students, and no funds to purchase anything. These
deployments depend on donated equipment from organizations and
individuals on the right side of the gap.
This, of course, is the fundamental problem of SOAS. It serves an
environment where a child has access to a computer at home and sometimes
one at school. SOAS makes it possible for the student to carry the
learning environment between the two worlds. However, on the wrong side
of the gap, there is no concept of a computer at school and a second at
home. In many cases the reality is that there is no electricity at home.
In this environment Sugar needs to be installed on the local storage of
the computer.
These millions of Android devices have a basic problem - they depend on
connection to a network. In additon, the UI is designed for consumption
and is not conducive to constructive learning. How many of its myriads
of education apps are available open-source, free and for offline use?
Sugarizer and GCompris show that it is possible to work around this
design and its hyper-commercialized face.
In the meantime, miraculously there may be a school with Sugar on XOs
and, hopefully, a schoolserver to stand in for the internet. Even more
hopefully, the school allows the children to take a computer home with
content to work on which was downloaded from the schoolserver (so far, a
dream generally unfulfilled).
OLPC is fading not just as an organization but as a concept. Even some
of our most robust OLPC deployments are moving to the computer lab
model. The Raspberry Pi in, for example, the Computer for Kids
deployments, is in a lab (the computer with keyboard, monitor and
without a battery is not portable). The only hope for constructive
education is to find a way that these labs can be made available to
students after-hours or on weekends for unprogrammed use. This critical
issue seems invisible to the Sugar Labs community.
One requirement that our current developers seem to have forgotten is
that in an environment without the internet, students need to download
content to the laptop so they can work with it away from the school
server or other network resource. How does a student read Alice in
Wonderland online in a classroom or computer lab? This implies a school
server which serves the content from the internet selectively to
computers with very limited storage capacity. Hand-waving at the
internet like the Get Books activity or web services is relevant in
Boston or other location with 24/7 broadband internet but not on the
other side of the gap. Modifying Browse to replace the Read and Jukebox
activities without support for downloading the media and playing it from
the Journal is similarly misdirected.
Given that neither students or teachers in this environment have been
brought up in a 'computer culture', without help - nothing happens. It
is not economically feasible to provide counselors to work directly with
the teachers to stage, for example, a Turtle Art day (i.e. as a way to
introduce teachers and students to new capabilities available on the
computer). My current focus is on providing 'turtleart day-like'
documentation showing students how to perform tasks step-by-step to
explore new capabilities. In Rwanda, this led to teacher training on how
to access and use the documentation - with the documentation available
through the school year. Since there was no funding for a schoolserver,
this led to a roomserver - serving the documentation and other content
from an SD card using SimpleHTTPServer.py and the adhoc networks.
The new science curriculum in Rwanda, thanks to the efforts of Eric
Kemenyi at Rwanda Education Board, calls for school-age children to
learn programming in Scratch, Etoys or Turtle Art. Amazingly, Sugar
supports all three plus learning to program in Python and in web
technology (static: html/css and animated: javascript). This is not to
mention the essential tool for Linux users, bash scripting.
Imagine the excitement of a primary school student who discovers that it
is possible to write a program in python (e.g. hello world) and have
this program appear on the Home View (with the help of Pippy). Imagine
the motivation to learn to make a custom icon for the program in svg.
Imagine the motivation to make the program available to classmates by
collaboration or via a schoolserver. This is the way constructive
education should work - get a learner started at a simple level and show
the path to increasing capability.
The educational potential of Sugar is amazing and amazingly neglected.
Consider that we have deployments in Uruguay and Peru which have
resulted in every person in both countries under the age of 20 being
familiar with Sugar. The Sugar Labs community appears to be totally
oblivious to this experience with remarks like - are there any computers
with 13.2.8 installed? As most of you know, a pet peeve of mine is that
localization is viewed by Sugar Labs as a professional enterprise, not a
learning opportunity for our users.
Arguably, Sugar Labs has more experience with promoting constructive 1-1
learning supported by computers than anyone on the planet. What
advantage are we taking of this experience? Why don't we know how many
laptops are deployed within a factor of 10? Why don't we know what
version of Sugar is installed. (It is easy for developers to update
Sugar hourly but it is another story to take Sugar on a three-day hike
in the Andes to reflash the XOs). Most importantly, why don't we know
what are the successes and failures of these deployments? Try to name a
feature of Sugar introduced based on the experience of one of our
deployments.
None of this has to do with the age of the XO. It is still the only
alternative for deployments envisioned by the OLPC concept. Its design
brilliantly met this requirement. Unlike brake pads, electronics don't
wear out. There are components such as the battery that do. The
solid-state store apparently does also.
So naturally, it would be helpful to have in serial production a $200
laptop with the capabilities of the XO for new or expanding deployments.
I have been looking for the past five years but have not found anything
even close to a viable alternative.
Keeping the XOs running needs some product development. First, we need a
replacement battery whose design avoids current transport restrictions
on lithium batteries. The solid-state problem is much simpler: On the
XO-1, go to the sd card image. On the later models, replace the micro-sd
chip. In deployments, the major problem with the XO is not performance,
it is storage capacity.
Tony
On 03/01/2017 06:04 PM, Dave Crossland wrote:
Thanks for clarifying :)
The question remains then: Is Sugar Labs to direct attention entirely
to a few hundreds of very-to-somewhat old XO laptops maintained by
experts like Tony and those in Caacupe, or to the millions of children
who have computers/tablets capable of accessing/installing Sugarizer,
or to some mix of the two; and if the latter, what mix is appropriate
in 2017 and 2018?
On 1 March 2017 at 05:26, Tony Anderson <tony_ander...@usa.net
<mailto:tony_ander...@usa.net>> wrote:
All models are obviously xo-1, xo-1.5, xo-1.75 and xo-4. Sugarizer
is not relevant since the XOs deploy Sugar. The Sugarizer
activities are mostly also available as Sugar web activities. We
are using the Python Turtle blocks.
Tony
On 02/28/2017 02:29 PM, Dave Crossland wrote:
On Feb 27, 2017 11:34 PM, "Tony Anderson" <tony_ander...@usa.net
<mailto:tony_ander...@usa.net>> wrote:
For what it's worth, Sugar 0.110 (OLPC OS 13.2.8) has been
installed on hundreds of XO laptops, all models in Rwanda.
The codebase is reaching these classrooms.
That is great to know!!! :)
What xo models are those?
Does anyone know of any other classrooms using the latest release?
I am not sure what you mean by the js codebase, but if you
mean the sugar web activities. Yes they are available for
optional installment (along with the other activities in ASLO)
Sugarizer
--
Cheers
Dave
_______________________________________________
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep
