[IAEP] Sugar Labs 2017 Budget

[Samson Goddy]

+1 Tony you deserved an Oscar. Am i the only thinking we just got a mission
and vision plan based on Tony explanation?

Samson

On 2 Mar 2017 3:44 am, "Tony Anderson" <tony_anderson at usa.net> wrote:

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_anderson at 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_anderson at 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 at lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/iaep/attachments/20170302/4aa09c4e/attachment-0001.html>