Greetings, 

Our company and developers are interested in getting involved with the 
development community for Sugar. We deploy Linux desktop solutions in schools 
in the United States via thin client and fat client methods. We believe that 
Sugar's collaboration tools, journal,  and other features could be very 
appealing to younger grade (elementary and middle school) students and 
teachers. Several of our schools are interested in using Sugar in the 
classrooms already on their thin client desktops.   

We have the Ubuntu packages running fine, but it is evident that there are 
changes that should be made to Sugar when its not being used on the OLPC. Some 
of the challenges for deploying Sugar on desktops in a school environment are 
different than using it on standalone OLPCs, which need to be overcome for 
Sugar to take a major foothold independent of the OLPC. Below we have listed 
some of the issues we think need to be addressed based on our experience with 
working in schools.    
 
The technical challenges we see are mostly problems integrating sugar into a 
thin client architecture, and into the networks of schools. One of the most 
immediate changes we will need to make are customizations to the interface. For 
example, thin clients may not need the shutdown and reboot options, and need a 
logout option. There are other customizations that we may need to make, such as 
adding or removing items from the control panel. These sorts of changes are 
small, and once done will allow people to deploy sugar in a small classroom 
environment.

On larger installations, schools will want sugar to integrate with there 
existing file and print servers, as well as some centralized administration of 
the sugar interface. Ideally, the journal and datastore would be stored on the 
file server in such a way as to allow teachers to access the saved activities 
from a normal Windows or Linux computer. It would be interesting to see if we 
could launch sugar activities without running the entire sugar interface. Also, 
local media attached to thin client may pose a challenge, as the normal ways to 
search for and mount media are not available.

Another important aspect of larger sugar deployments would be the ability of 
admins to customize the user interface. For example they may not want users to 
have access to the control panel, or may want to set up the list of activities 
per grade, and prevent users from installing there own activities.

One of the most interesting aspects of sugar is its collaboration features, but 
this too poses some difficulties. In multi classroom environments its not clear 
how the collaboration would work. Ideally there would be one jabber server for 
the entire network. This would mean that every student on the network could see 
every other student on the network, when the desired behavior may be to only 
see the students in the current class. 

These are some of the issues were thinking about. We could solve most of these 
problem by creating our own custom build of sugar with the patches needed to 
integrate with our current software. However, we would rather work with the 
community to create solutions to the problems. For example, one of the things 
we would like to do is to extend the profile class to allow for multiple back 
ends, as well as the ability to store generic settings. This would allow us to 
integrate some of the important profile settings, such as the jabber server, 
into our management software, while at the same time keeping a consistent API 
and keeping our code separate from the sugar tree. 
 
We are very excited about the possibilities that sugar provides. We look 
forward to contributing to this project, and we are interested in your thoughts 
about these issues.



-----------------------
Brendan Powers
Resara LLC

1.888.357.9195
www.resara.com

_______________________________________________
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Reply via email to