So, Bernie was quick and gave me access to our new server where just finished installing AMO by translating the instructions here to Intrepid. Everything ran smoothly and we have it up and running now: http://addons.sugarlabs.org
This is in early test stages and data will be often cleared as we install new versions. The main intent of this public server is for the people that wish to get involved in this effort to have a common place where to put their advances.
Stuff left to do:
- Fix search
- Fix downloads
- Lots of testing, debugging and fixing
- Upstream all patches that can make easier future rebases (and have a chance of being accepted)
- Choose a domain name, I'm not sure 'addons' is the best one
- Translate our new strings
- Change the design accordingly to the Sugar image
- ...
People interested in joining could take the http://sugarlabs.org/go/DevelopmentTeam/a.s.o namespace and set up some pages to coordinate themselves. Or maybe somewhere inside http://sugarlabs.org/go/InfrastructureTeam . The skills required are those of a php web developer.
Saturday, December 20, 2008
addons.mozilla.org for Sugar
During the last two weeks I have been working on adapting Mozilla's addons site to the Sugar needs.
After some fighting with php code and basing on previous work from David Farning, managed to install it in a virtual machine and write some patches so that AMO accepts activity bundles.
Bernie is going to resume the work where I left and I hope we'll have a test instance in a public server sometime soon. Then we'll need to give it some testing, fix the remaining bugs and customize the look to SugarLab's graphical identity.
Also, as we are forking their code, we are going to update regularly with upstream and maintain our set of patches, that I hope can keep small and not too intrusive. There are also some opportunities to upstream some work that can make this work lighter, as Mozilla is also interested in making easier adding new addon types.
So there's quite a bit of work left to do, but I believe that this project will give Sugar much more projection. I see as fundamental to our goals that it's as easy as possible to discover and install new activities and to publish new ones. If you have php coding skills, please give a hand!
After some fighting with php code and basing on previous work from David Farning, managed to install it in a virtual machine and write some patches so that AMO accepts activity bundles.
Bernie is going to resume the work where I left and I hope we'll have a test instance in a public server sometime soon. Then we'll need to give it some testing, fix the remaining bugs and customize the look to SugarLab's graphical identity.
Also, as we are forking their code, we are going to update regularly with upstream and maintain our set of patches, that I hope can keep small and not too intrusive. There are also some opportunities to upstream some work that can make this work lighter, as Mozilla is also interested in making easier adding new addon types.
So there's quite a bit of work left to do, but I believe that this project will give Sugar much more projection. I see as fundamental to our goals that it's as easy as possible to discover and install new activities and to publish new ones. If you have php coding skills, please give a hand!
Mind mapping SugarCamp '08
John Tierney was busy during the SugarCamp and draw several mind maps about what was discussed during the talks.
So check them out if you couldn't attend or if you would like to rethink a bit about those issues.
So check them out if you couldn't attend or if you would like to rethink a bit about those issues.
Friday, December 19, 2008
New feature: Object transfer in the journal
So these two last weeks were about coding. Landed the first batch of patches that bring file transfer to the journal and, though more or less working, still need a lot of love and polishing. Next week plan to resume work on file transfer as the last days I have been working on adapting http://addons.mozilla.org to serve activities. More on this in the next post.
The plan is to implement Eben's spec:
As an important implementation detail, we are using Telepathy as a central piece of our collaboration stack, and the mechanism we use for transferring files is the same that an instant messaging client would use to transfer files from GNOME, etc. Right now, telepathy supports only file transfer in its Salut backend (so LAN only) but in the near future we expect to have it added to the Jabber backend so we'd get for free file transfer supported in all our collaboration scenarios.
A big thanks to the telepathy guys at Collabora for their support and great work. And special thanks to Guillaume for his patience at answering my questions.
The plan is to implement Eben's spec:
As an important implementation detail, we are using Telepathy as a central piece of our collaboration stack, and the mechanism we use for transferring files is the same that an instant messaging client would use to transfer files from GNOME, etc. Right now, telepathy supports only file transfer in its Salut backend (so LAN only) but in the near future we expect to have it added to the Jabber backend so we'd get for free file transfer supported in all our collaboration scenarios.
A big thanks to the telepathy guys at Collabora for their support and great work. And special thanks to Guillaume for his patience at answering my questions.
Thursday, December 11, 2008
Again a volunteer
Monday was my last day as a contractor for OLPC. Has been hard to work with these guys but now I feel grateful that for almost two years I have been given the chance to work together with them in so many hard issues. They for sure have many interesting challenges to tackle and the technical ones aren't by far the most difficult.
I'm not going very far for some time, though. My plan now is to keep working in Sugar as a volunteer for as long as my savings last. Just as I was a volunteer for OLPC before they contracted me.
As I have written recently here, many people and organizations outside from OLPC have shown enormous interest in Sugar as a learning platform, so my goal now is to make possible for as many people to collaborate in SugarLabs as it can be. We need more deployers, developers, testers, writers, educators, designers,... and I trust we are on the right path to offer them a place where everybody can play. Be from local labs or the global SugarLabs.
So I'm happy because now I'll be able to focus all my energy on improving Sugar and help taking it to more children. Now I need to stop blogging nonsense and go back coding ;)
I'm not going very far for some time, though. My plan now is to keep working in Sugar as a volunteer for as long as my savings last. Just as I was a volunteer for OLPC before they contracted me.
As I have written recently here, many people and organizations outside from OLPC have shown enormous interest in Sugar as a learning platform, so my goal now is to make possible for as many people to collaborate in SugarLabs as it can be. We need more deployers, developers, testers, writers, educators, designers,... and I trust we are on the right path to offer them a place where everybody can play. Be from local labs or the global SugarLabs.
So I'm happy because now I'll be able to focus all my energy on improving Sugar and help taking it to more children. Now I need to stop blogging nonsense and go back coding ;)
Saturday, December 6, 2008
Why Sugar?
Or rather, why to spend a significant part of my life in this project?
To make it short, it's because I see how computers have failed many people around me.
I was lucky to grow in a family that, though not affluent, had ready access to computers. First it was a Macintosh (128K), then came a Mitsubishi MSX and in the next 15 years several models of Apple and PC-compatibles followed. One outcome of this was that my brother and me grew up playing, programming and tinkering with the different platforms, and my mother earned a live with desktop publishing. But, my sister, father and grandparents (who lived in a flat below ours) didn't particularly benefited from those computers. Why?
In a similar way, about 90% of my classmates only ever used computers during their studies because we passed one hour every week in the computer lab and a teacher would evaluate their knowledge about how to put files inside folders, use bold and italic fonts in text documents and sum up columns of numbers. At the end, they didn't benefited from the computers they had access to. Why?
Perhaps it's because those totally capable people couldn't justify in their minds to spend an indeterminate amount of effort in order to gain a very fuzzy benefit, something very reasonable, I would say. During the last 10 years, our societies have increased awareness of the benefits of computing, so more and more people have decided to make bigger efforts to use computers. But we are still failing a very significant part of our communities. Why?
Maybe, because the effort required to use computers hasn't decreased much during these years. That's why I think that the UIs that so efficiently geeks like me are using aren't enough when we want to bring the benefits of computers to all people.
And how can Sugar help to improve this situation? I see Sugar as two things in this regard: a common place where people who care about extending access to computing can work together, and a software platform where we are free to break assumptions and provide a better user experience to the use case we care most about: education.
If you go to the Ubuntu forums or call Microsoft's user support and propose a change to their software that benefits the educational use of their software but needs to change in some way how office workers use their UI, you will be told more or less politely to go ask somewhere else. But not in Sugar, as we have the power to actually change things and will welcome any idea that improves how people learn with their computers.
In case it's not clear yet, I understand how people that are happy with how they use their computers today can find Sugar a waste of time and how they can decide to be opposed to many computers around them run such an unfamiliar UI. But what I want to stress is that we are not saying that we are going to make Sugar a platform _you_ will be happier to use (though we'd love that, of course), what we say is that something is wrong with today's computers and something needs to be done.
So, share your ideas (and code!) about why Sugar sucks and how it can be improved. But please, stop repeating that existing desktops are just fine and we shouldn't be reinventing the wheel. From where I stand, I only see squared wheels and there must be something better!
To make it short, it's because I see how computers have failed many people around me.
I was lucky to grow in a family that, though not affluent, had ready access to computers. First it was a Macintosh (128K), then came a Mitsubishi MSX and in the next 15 years several models of Apple and PC-compatibles followed. One outcome of this was that my brother and me grew up playing, programming and tinkering with the different platforms, and my mother earned a live with desktop publishing. But, my sister, father and grandparents (who lived in a flat below ours) didn't particularly benefited from those computers. Why?
In a similar way, about 90% of my classmates only ever used computers during their studies because we passed one hour every week in the computer lab and a teacher would evaluate their knowledge about how to put files inside folders, use bold and italic fonts in text documents and sum up columns of numbers. At the end, they didn't benefited from the computers they had access to. Why?
Perhaps it's because those totally capable people couldn't justify in their minds to spend an indeterminate amount of effort in order to gain a very fuzzy benefit, something very reasonable, I would say. During the last 10 years, our societies have increased awareness of the benefits of computing, so more and more people have decided to make bigger efforts to use computers. But we are still failing a very significant part of our communities. Why?
Maybe, because the effort required to use computers hasn't decreased much during these years. That's why I think that the UIs that so efficiently geeks like me are using aren't enough when we want to bring the benefits of computers to all people.
And how can Sugar help to improve this situation? I see Sugar as two things in this regard: a common place where people who care about extending access to computing can work together, and a software platform where we are free to break assumptions and provide a better user experience to the use case we care most about: education.
If you go to the Ubuntu forums or call Microsoft's user support and propose a change to their software that benefits the educational use of their software but needs to change in some way how office workers use their UI, you will be told more or less politely to go ask somewhere else. But not in Sugar, as we have the power to actually change things and will welcome any idea that improves how people learn with their computers.
In case it's not clear yet, I understand how people that are happy with how they use their computers today can find Sugar a waste of time and how they can decide to be opposed to many computers around them run such an unfamiliar UI. But what I want to stress is that we are not saying that we are going to make Sugar a platform _you_ will be happier to use (though we'd love that, of course), what we say is that something is wrong with today's computers and something needs to be done.
So, share your ideas (and code!) about why Sugar sucks and how it can be improved. But please, stop repeating that existing desktops are just fine and we shouldn't be reinventing the wheel. From where I stand, I only see squared wheels and there must be something better!
Thursday, December 4, 2008
Walk through a small modification to Sugar
Some weeks ago, Sugar gained a general way for inspecting the source of any activity:
On OLPC's XO, that dialog is triggered by hitting Fn+space, and the space bar is conveniently tagged with a gear to indicate that. But we want Sugar to run equally well on other machines, so if we use a shortcut like alt-ctrl-v, we need to display it in the UI somehow so it's discoverable. One solution is to add an entry to the activity palette and show the shortcut there. This is the palette before the modification:
I'm going to do this modification and will try to explain here the process I followed. Please ask in the comments below any clarifications you need, though I'm going to assume that you have managed to install and run successfully sugar in jhbuild, see http://sugarlabs.org/go/DevelopmentTeam/Jhbuild for more details.
Also, you will need to have some knowledge of PyGTK in order to do similar modifications of Sugar, though going through the PyGTK tutorial should be enough: http://www.pygtk.org/pygtk2tutorial/index.html
So, first thing is to check out where is the palette (menu) that we want to add the item to. For that, one way is to see a string that appears in that palette and grep the shell sources for it:
$ cd ~/sugar-jhbuild/source/sugar
$ grep -R Resume src
That results in four files, so we need to decide which one is the right one:
src/jarabe/journal/palettes.py: resume_label = _('Resume')
src/jarabe/journal/journaltoolbox.py: self._resume.set_tooltip(_('Resume'))
src/jarabe/desktop/meshbox.py: item = MenuItem(_('Resume'), 'activity-start')
src/jarabe/view/palettes.py: menu_item = MenuItem(_('Resume'), 'activity-start')
The modification we want to do is not in the journal nor in the mesh view, so we decide we are going to look into src/jarabe/view/palettes.py.
If we search inside that file, we can see that that line is inside the constructor of CurrentActivityPalette, so that seems indeed the place where we want to add the view source menu item.
So with a bit of copy pasting, we can base on the Resume menu item and add our View source one:
diff --git a/src/jarabe/view/palettes.py b/src/jarabe/view/palettes.py
index 5ba2cc2..ca7b079 100644
--- a/src/jarabe/view/palettes.py
+++ b/src/jarabe/view/palettes.py
@@ -63,6 +63,12 @@ class CurrentActivityPalette(BasePalette):
self.menu.append(menu_item)
menu_item.show()
+ # TODO: ask Eben for a nice icon for this menu entry
+ menu_item = MenuItem(_('View source'), 'activity-start')
+ menu_item.connect('activate', self.__view_source_activate_cb)
+ self.menu.append(menu_item)
+ menu_item.show()
+
# TODO: share-with, keep
separator = gtk.SeparatorMenuItem()
@@ -77,6 +83,9 @@ class CurrentActivityPalette(BasePalette):
def __resume_activate_cb(self, menu_item):
self._home_activity.get_window().activate(gtk.get_current_event_time())
+ def __view_source_activate_cb(self, menu_item):
+ logging.debug('View source menu item was activated!')
+
def __stop_activate_cb(self, menu_item):
self._home_activity.get_window().close(1)
So, after running make install and sugar-emulator, we can see how the launched activities have that extra menu item:
And what happens when we click on it? An error :(
Traceback (most recent call last):
File "/home/tomeu/sugar-jhbuild/install/lib/python2.5/site-packages/jarabe/view/palettes.py", line 87, in __view_source_activate_cb
logging.debug('View source menu item was activated!')
NameError: global name 'logging' is not defined
You can see those lines printed in the same terminal window where you ran sugar-emulator. The problem is a missing import logging so we can just add that and try again.
The next step is to add an accelerator to that menu item, and finally actually do something when the user clicks on that menu item, but that will have tomorrow as I _really_ need to go cook dinner.
On OLPC's XO, that dialog is triggered by hitting Fn+space, and the space bar is conveniently tagged with a gear to indicate that. But we want Sugar to run equally well on other machines, so if we use a shortcut like alt-ctrl-v, we need to display it in the UI somehow so it's discoverable. One solution is to add an entry to the activity palette and show the shortcut there. This is the palette before the modification:
I'm going to do this modification and will try to explain here the process I followed. Please ask in the comments below any clarifications you need, though I'm going to assume that you have managed to install and run successfully sugar in jhbuild, see http://sugarlabs.org/go/DevelopmentTeam/Jhbuild for more details.
Also, you will need to have some knowledge of PyGTK in order to do similar modifications of Sugar, though going through the PyGTK tutorial should be enough: http://www.pygtk.org/pygtk2tutorial/index.html
So, first thing is to check out where is the palette (menu) that we want to add the item to. For that, one way is to see a string that appears in that palette and grep the shell sources for it:
$ cd ~/sugar-jhbuild/source/sugar
$ grep -R Resume src
That results in four files, so we need to decide which one is the right one:
src/jarabe/journal/palettes.py: resume_label = _('Resume')
src/jarabe/journal/journaltoolbox.py: self._resume.set_tooltip(_('Resume'))
src/jarabe/desktop/meshbox.py: item = MenuItem(_('Resume'), 'activity-start')
src/jarabe/view/palettes.py: menu_item = MenuItem(_('Resume'), 'activity-start')
The modification we want to do is not in the journal nor in the mesh view, so we decide we are going to look into src/jarabe/view/palettes.py.
If we search inside that file, we can see that that line is inside the constructor of CurrentActivityPalette, so that seems indeed the place where we want to add the view source menu item.
So with a bit of copy pasting, we can base on the Resume menu item and add our View source one:
diff --git a/src/jarabe/view/palettes.py b/src/jarabe/view/palettes.py
index 5ba2cc2..ca7b079 100644
--- a/src/jarabe/view/palettes.py
+++ b/src/jarabe/view/palettes.py
@@ -63,6 +63,12 @@ class CurrentActivityPalette(BasePalette):
self.menu.append(menu_item)
menu_item.show()
+ # TODO: ask Eben for a nice icon for this menu entry
+ menu_item = MenuItem(_('View source'), 'activity-start')
+ menu_item.connect('activate', self.__view_source_activate_cb)
+ self.menu.append(menu_item)
+ menu_item.show()
+
# TODO: share-with, keep
separator = gtk.SeparatorMenuItem()
@@ -77,6 +83,9 @@ class CurrentActivityPalette(BasePalette):
def __resume_activate_cb(self, menu_item):
self._home_activity.get_window().activate(gtk.get_current_event_time())
+ def __view_source_activate_cb(self, menu_item):
+ logging.debug('View source menu item was activated!')
+
def __stop_activate_cb(self, menu_item):
self._home_activity.get_window().close(1)
So, after running make install and sugar-emulator, we can see how the launched activities have that extra menu item:
And what happens when we click on it? An error :(
Traceback (most recent call last):
File "/home/tomeu/sugar-jhbuild/install/lib/python2.5/site-packages/jarabe/view/palettes.py", line 87, in __view_source_activate_cb
logging.debug('View source menu item was activated!')
NameError: global name 'logging' is not defined
You can see those lines printed in the same terminal window where you ran sugar-emulator. The problem is a missing import logging so we can just add that and try again.
The next step is to add an accelerator to that menu item, and finally actually do something when the user clicks on that menu item, but that will have tomorrow as I _really_ need to go cook dinner.
SugarCamp Nov 08 (Part II)
Wednesday Nov 19th
Wednesday was the day that was most focused on technical issues.
Scott gave an interesting talk about what we can do to improve Sugar integration with traditional Unix desktops, though, as Marco pointed out during the talk, about half of that was already done ;) Check out the slides here.
In my opinion, the most important reason behind Sugar's success despite the very small resources available, is how we (though Marco needs to be credited as being the pusher for this) took advantage of the infrastructure already available in GNOME (or most specifically, GNOME Mobile). Sugar shouldn't be seen (from the architectural point of view) as a system on par with GNOME, KDE or Xfce, but rather as a peer of Nokia's Maemo and Canonical's Ubuntu Mobile, building on the GNOME Mobile platform.
Edward Cherlin talked next about important work that needs to be done in order to achieve OLPC's goals, but nobody has taken the initiative yet. This includes electric power distribution and generation, local entrepreneurial, content creation, etc. We at SugarLabs really need to find a way to work together with all organizations that share goals with us, and Local Labs will have a critical responsibility there.
Then was Martin Langhoff's turn, he spoke about the school server, the work done by now and the next steps. His small team of one person can only focus on OLPC's priorities for now, but I hope we'll find ways to use his work in non-OLPC deployments and contribute back some good stuff.
Sayamindu Dasgupta explained the work he has been doing lately to improve our localization infrastructure: language packs that can be deployed at a later stage than code deployment and supporting multiple fallback languages for regions where several languages are used and not all have a complete translation coverage. Scott showed us how our UI elements could be translated in place by users and we had some talk about the issues of consolidating that work.
After dinner Scott explained his view about the networking issues that OLPC faces.
UPDATE: Scott corrects me by saying that Wednesday night he actually talked about some miscellaneous topics.
Thursday Nov 20th
Early that morning Solution Grove's Caroline Meeks brought Marco, Bernie and me to visit the Thomas Gardner elementary school, where a Sugar on a Stick pilot may happen sometime next year. We got to see how the computer lab was set up, which infrastructure was in place, got the opportunity to ask about how kids used the computers in the lab, how classes were conducted and some of the interesting problems that the school faces and that Sugar could help with. A very inspiring time that makes me want to make sure that the next Sugar release (0.84) has all what is needed to conduct the pilot with success.
That visit made us arrive late to the first talk of the day, Greg Smith's "How Sugar Labs could better work with OLPC in satisfying their customers". As interesting as the school visit was, I felt very sorry to miss the first half of that talk because Greg really knows how to care about customers. There's lots to learn there and we would better understand how to work together with our users if we want to succeed. Checkout the slides. I would vote for him to give the same talk in our next half-dozen Sugarcamps, at least.
Nice presentation by Brendan and Caroline about their plans of using Sugar in schools in the US. We have some challenges to solve in order for them to be able to successfully deploy Sugar as they plan to, but we must succeed if we want to gain the enormous momentum that deployments in developed countries can give to Sugar in the short (1-2 years) term. As said above, Caroline plans to pilot Sugar in schools were every kid has a usb stick with a complete Sugar solution on it, and Brendan is working on deploying Sugar in thin clients. See more details in their beautiful slides.
OLPC's Ed McNierney talked with us about which are going to be the priorities for OLPC in software development. He explained that the focus would be "deployability", meaning by that all that can make easier for laptops to get into children's hands. Turned out that Sugar seems to be working pretty well for them, so work is mainly needed in: rebasing on F10, power management, localization/translation, activation/lease/signing/management, run linux and any linux app easily. Some of those areas involve Sugar modifications, though not of much use to other deployers of Sugar.
Given that OLPC is today the only organization putting development resources into Sugar and that they don't plan to work on further improving the platform as a whole, our roadmap for 0.84 is seriously questioned. So Marco decided to cancel his talk about the roadmap and instead talk further with OLPC employees about the areas in which we could work together. Unfortunately, those hours were finally spent in talking about OLPC issues not related to Sugar and we decided to leave the meeting room and focus on other stuff instead.
On the bright side, OLPC hasn't decided yet on what their contractors should work instead, so we keep working in the meantime on the original roadmap that we decided some months ago at the start of the 0.84 cycle.
Friday Nov 21th
Friday was dedicated to matters of a more organizational nature, though we started with a presentation on how Sugar could integrate the concept of a Portfolio. Giving better tools to children for them to explain their own work fits very well with our educational goals but also matches a growing trend in developed countries for kids to be a more active part in their own evaluation. Unfortunately, I missed most of this talk because my little brain wasn't able to follow the constant changes to the schedule. Slides here.
Walter gave next an overview of what have been the first 6 months of SugarLabs. We have covered lots of ground in the constitution of a community and an organization to support it and we have a clear idea of what our next challenges are. Check out the slides, they start with a very good introduction of SugarLabs' goals, mission and strategy.
Greg DeKoenigsberg lead a discussion on what the job of SugarLabs' marketing team would be and it resulted in a brainstorm about which message we want to communicate about SugarLabs.
After lunch we had a presentation by Pentagram's Christian Marc Schmidt and OLPC's Eben Eliason that I was eagerly waiting: Design opportunities for Sugar. It was a session packed with a thorough explanation of the principles behind Sugar's UI, several very interesting ideas about how to further develop its design goals and how to solve some issues that were discovered after actual use of Sugar by students and teachers. The presentation resulted very stimulating for the presents and several interesting discussions were started, though Michael Stone seemed to be specially excited by the talk and his frequent comments caused the talk to be rushed at the end. Check out the slides linked above because they are really awesome.
Scott continued presenting his ideas about how collaboration can better work in the scenarios that OLPC cares most about, and we found a way through which he can improve Sugar's support for those without disrupting the more mainstream use cases, which are presently working pretty well. So we are going to further work inside the telepathy stack that GNOME provides and OLPC developers will try to find alternative ways to provide a collaboration experience that works optimally in their deployments.
Saturday Nov 22th
Saturday started with some more work on marketing being led by Greg DeKoenigsberg. We worked on the elevator pitch and you can check out how this work further progresses here.
Then Adam Hyde from FLOSS Manuals talked with us about the very successful effort to create the Sugar manual and had some discussion about how best to translate this and other content like free-as-in-freedom textbooks.
Bernie presented next his awesome work on SugarLabs infrastructure and discussed with us how to move next. We keep considering several alternatives for acquiring a new machine and for hosting our services. Bernie has been doing big efforts in finding the best way to involve more volunteers that take the responsibility of maintaining the different pieces of SugarLabs' infrastructure.
Then Marco finally got to explain where we are regarding the engineering roadmap and we defined the major areas in which we need to work in this development cycle, check out the transcription of the whiteboard here. There's a lot of uncertainty regarding which resources OLPC will devote to this, but we need to move forward in any case.
Scott expressed his intention of working on a replacement for the Journal in Sugar, but as he wasn't able to pledge that his work could land during this development cycle, I will have to keep developing the old journal, that is getting a new datastore, entry network transfer and hopefully several usability improvements.
Scott's plans are very ambitious and if his new journal is not able to land at time for 0.84, we should make sure it does for 0.86.
To end this week talks, Mel conducted an experiment with us, the result of it can be found here.
Well, at last this got written, hope it helped a bit those who weren't able to attend. Next time I attend a Sugarcamp, I will think twice before offering to write about it.
Wednesday was the day that was most focused on technical issues.
Scott gave an interesting talk about what we can do to improve Sugar integration with traditional Unix desktops, though, as Marco pointed out during the talk, about half of that was already done ;) Check out the slides here.
In my opinion, the most important reason behind Sugar's success despite the very small resources available, is how we (though Marco needs to be credited as being the pusher for this) took advantage of the infrastructure already available in GNOME (or most specifically, GNOME Mobile). Sugar shouldn't be seen (from the architectural point of view) as a system on par with GNOME, KDE or Xfce, but rather as a peer of Nokia's Maemo and Canonical's Ubuntu Mobile, building on the GNOME Mobile platform.
Edward Cherlin talked next about important work that needs to be done in order to achieve OLPC's goals, but nobody has taken the initiative yet. This includes electric power distribution and generation, local entrepreneurial, content creation, etc. We at SugarLabs really need to find a way to work together with all organizations that share goals with us, and Local Labs will have a critical responsibility there.
Then was Martin Langhoff's turn, he spoke about the school server, the work done by now and the next steps. His small team of one person can only focus on OLPC's priorities for now, but I hope we'll find ways to use his work in non-OLPC deployments and contribute back some good stuff.
Sayamindu Dasgupta explained the work he has been doing lately to improve our localization infrastructure: language packs that can be deployed at a later stage than code deployment and supporting multiple fallback languages for regions where several languages are used and not all have a complete translation coverage. Scott showed us how our UI elements could be translated in place by users and we had some talk about the issues of consolidating that work.
UPDATE: Scott corrects me by saying that Wednesday night he actually talked about some miscellaneous topics.
Thursday Nov 20th
Early that morning Solution Grove's Caroline Meeks brought Marco, Bernie and me to visit the Thomas Gardner elementary school, where a Sugar on a Stick pilot may happen sometime next year. We got to see how the computer lab was set up, which infrastructure was in place, got the opportunity to ask about how kids used the computers in the lab, how classes were conducted and some of the interesting problems that the school faces and that Sugar could help with. A very inspiring time that makes me want to make sure that the next Sugar release (0.84) has all what is needed to conduct the pilot with success.
That visit made us arrive late to the first talk of the day, Greg Smith's "How Sugar Labs could better work with OLPC in satisfying their customers". As interesting as the school visit was, I felt very sorry to miss the first half of that talk because Greg really knows how to care about customers. There's lots to learn there and we would better understand how to work together with our users if we want to succeed. Checkout the slides. I would vote for him to give the same talk in our next half-dozen Sugarcamps, at least.
Nice presentation by Brendan and Caroline about their plans of using Sugar in schools in the US. We have some challenges to solve in order for them to be able to successfully deploy Sugar as they plan to, but we must succeed if we want to gain the enormous momentum that deployments in developed countries can give to Sugar in the short (1-2 years) term. As said above, Caroline plans to pilot Sugar in schools were every kid has a usb stick with a complete Sugar solution on it, and Brendan is working on deploying Sugar in thin clients. See more details in their beautiful slides.
OLPC's Ed McNierney talked with us about which are going to be the priorities for OLPC in software development. He explained that the focus would be "deployability", meaning by that all that can make easier for laptops to get into children's hands. Turned out that Sugar seems to be working pretty well for them, so work is mainly needed in: rebasing on F10, power management, localization/translation, activation/lease/signing/management, run linux and any linux app easily. Some of those areas involve Sugar modifications, though not of much use to other deployers of Sugar.
Given that OLPC is today the only organization putting development resources into Sugar and that they don't plan to work on further improving the platform as a whole, our roadmap for 0.84 is seriously questioned. So Marco decided to cancel his talk about the roadmap and instead talk further with OLPC employees about the areas in which we could work together. Unfortunately, those hours were finally spent in talking about OLPC issues not related to Sugar and we decided to leave the meeting room and focus on other stuff instead.
On the bright side, OLPC hasn't decided yet on what their contractors should work instead, so we keep working in the meantime on the original roadmap that we decided some months ago at the start of the 0.84 cycle.
Friday Nov 21th
Friday was dedicated to matters of a more organizational nature, though we started with a presentation on how Sugar could integrate the concept of a Portfolio. Giving better tools to children for them to explain their own work fits very well with our educational goals but also matches a growing trend in developed countries for kids to be a more active part in their own evaluation. Unfortunately, I missed most of this talk because my little brain wasn't able to follow the constant changes to the schedule. Slides here.
Walter gave next an overview of what have been the first 6 months of SugarLabs. We have covered lots of ground in the constitution of a community and an organization to support it and we have a clear idea of what our next challenges are. Check out the slides, they start with a very good introduction of SugarLabs' goals, mission and strategy.
Greg DeKoenigsberg lead a discussion on what the job of SugarLabs' marketing team would be and it resulted in a brainstorm about which message we want to communicate about SugarLabs.
After lunch we had a presentation by Pentagram's Christian Marc Schmidt and OLPC's Eben Eliason that I was eagerly waiting: Design opportunities for Sugar. It was a session packed with a thorough explanation of the principles behind Sugar's UI, several very interesting ideas about how to further develop its design goals and how to solve some issues that were discovered after actual use of Sugar by students and teachers. The presentation resulted very stimulating for the presents and several interesting discussions were started, though Michael Stone seemed to be specially excited by the talk and his frequent comments caused the talk to be rushed at the end. Check out the slides linked above because they are really awesome.
Scott continued presenting his ideas about how collaboration can better work in the scenarios that OLPC cares most about, and we found a way through which he can improve Sugar's support for those without disrupting the more mainstream use cases, which are presently working pretty well. So we are going to further work inside the telepathy stack that GNOME provides and OLPC developers will try to find alternative ways to provide a collaboration experience that works optimally in their deployments.
Saturday Nov 22th
Saturday started with some more work on marketing being led by Greg DeKoenigsberg. We worked on the elevator pitch and you can check out how this work further progresses here.
Then Adam Hyde from FLOSS Manuals talked with us about the very successful effort to create the Sugar manual and had some discussion about how best to translate this and other content like free-as-in-freedom textbooks.
Bernie presented next his awesome work on SugarLabs infrastructure and discussed with us how to move next. We keep considering several alternatives for acquiring a new machine and for hosting our services. Bernie has been doing big efforts in finding the best way to involve more volunteers that take the responsibility of maintaining the different pieces of SugarLabs' infrastructure.
Then Marco finally got to explain where we are regarding the engineering roadmap and we defined the major areas in which we need to work in this development cycle, check out the transcription of the whiteboard here. There's a lot of uncertainty regarding which resources OLPC will devote to this, but we need to move forward in any case.
Scott expressed his intention of working on a replacement for the Journal in Sugar, but as he wasn't able to pledge that his work could land during this development cycle, I will have to keep developing the old journal, that is getting a new datastore, entry network transfer and hopefully several usability improvements.
Scott's plans are very ambitious and if his new journal is not able to land at time for 0.84, we should make sure it does for 0.86.
To end this week talks, Mel conducted an experiment with us, the result of it can be found here.
Well, at last this got written, hope it helped a bit those who weren't able to attend. Next time I attend a Sugarcamp, I will think twice before offering to write about it.