[Sugar-devel] Activity Central's Sugar related priorities.
noiseehc at gmail.com
Wed Oct 9 16:51:51 EDT 2013
On 07/10/2013 18:41, David Farning wrote:
> Activity Central supports the recent HTML5 + JS work that is going
> into sugar .100. It has the potential to take the OLPC vision to any
> device which runs a browser while simultaneously *increasing* the
> potential activity *developer* *pool* by several orders of magnitude. This
> is an excellent area for community lead research. Activity Central
> will be doing activity side work to test the viability of the
> framework for client deployments.
No, it won't... It already happened when Bryan Berry moved OLPC Nepal's
lessons from EToys to Flash, then to HTML5 and there were not any more
contributors. I mean, there are much more JS developers, so if you pay
them you can get cheaper talent, but there will be not too much more
contributors IMHO. The problem is that the current HTML5 work goes into
a direction which I am not sure that needed by anyone other than
existing Sugar developers.
It all boils down to this simple question:
If you are a potential contributor wanting to develop some educational
activity (not a framework but some concrete lesson or stuff usable in a
lesson!!!) then which one would you use?
reaches 2-3 million children? (lets call it SWA)
reaches 1 billion children? (lets call it WEB)
I have not seen any compelling reason why would a potential contributor
(software developer from a developed country who has/likes children)
choose option 1 instead of 2...
Now I will not give you constructive criticism as that would allow
answering that "I should not tell others what to do" and it would be
getting old... Instead here is some nonconstructive criticism:
Some months ago I wanted to create a sample activity to present my point
but I have run out of time so unfortunately I cannot show it to you. It
would have been a Google Drive backed game with shared state (so the
same as a typical shared activity in Sugar) called Scrabble what I try
to port to SWA. It uses the following things which are trivial to use on
the WEB but cannot be found in SWA:
1. Sign in. There is no authorization API in SWA so using anything than
the local journal is problematic. Using Google's OAuth authentication
from a file:// protocol is impossible so if you want to support existing
code then you have to serve the activity from http://localhost...
2. Datastore. There is no way to access the Google Drive if you cannot
which accesses only the journal when they are already familiar with some
WEB technology. Like WEBDAV or the OpenStack's SWIFT API.
Or simply using POST for uploading:
3. Collaboration. Using the Google Drive Realtime API is dead simple. It
is the most missing feature from SWA BTW.
I have looked at several open source Operational Transformations
libraries but did not have time to test their performance on an XO...
4. Using WebSockets for simple tasks. The autosaving can be implemented
by the almost standard "webkitvisibilitychange" event (but you have to
compile webkit with the appropriate parameters) and standard timers.
Activity startup is simplified with per activity data store (POST-ing to
the same server is the default on the WEB). I think it eliminates the
communication with Sugar so no need for WebSockets...
5. Android port. There already exists a multi-platform technology called
PhoneGap. It can target 100-200 million children so it can be called
option 3 if you want... It can become obsolete as HTML5 provides more
and more of its features though.
So as I see you either create a framework which mimics Sugar and no web
developer will use it or create a framework which implements what a web
developer is already using or at least tries to somehow emulate it. So
the web developer does not have to modify his/her code and will consider
porting his/her application for a smaller platform. Of course that would
require OLPC/Sugarlabs to run free OpenStack/OAuth/OT servers for
contributors otherwise everybody will go with Google APIs which cannot
easily be emulated on an XO machine...
But as this discussion already happened and I have already written
enough now, I just finish here. (In the following link you can replace
the phrase "Per Activity Data Store" with "Standard WEB Storage" to be
Thank you for your attention!
Now to say something constructive as well, some more words about the
Journal. Recently I was watching one of Walter Bender's talks where he
was talking about that how sad that the Journal changed from something
the child writes into to a simple list (it was exemplified by showing a
Journal icon with and without the pen) because everybody hated that they
got the save prompt at activity exit. (The prompt is the lamest thing
according to usability 101 by the way...) The really sad thing is that
until that talk I did not really understand the importance of the
Journal, at least why was it so important to others like Walter... Using
my enlightenment I have tried to implement a new Journal in WEB with
Walter's vision in mind but of course time has run out...
So the UI design, which meshes perfectly with a "Per Activity Data Store":
1. The Journal is a list of links, activity links for starting the
activity and document links for opening/creating documents (which are
managed by the activity, which is a web page or a special local HTML5
activity). The launcher records activity starts and full text indexing
records activity document changes.
2. The Journal allows full text search to find documents. (It has to
store credentials to access Google Drive for example...)
3. The Journal allows to group entries under projects and project
stages, where the stages correspond to entries which are close to each
other in time. For example "Checking Plant Growth 15" project stage can
be using Camera, then using Photo Edit, then using Write (or Excel) to
4. Grouping entries is the only way to get rid of (collapse) all the
automatically created links, but also the time to write a description of
what did he/she do and why. This point was my plan to create an
5. Allow exporting projects (like "Growing a plant") automatically to
share with others in WEB format.
Hmmm, good luck with this plan.
I can share the C webkit activity code if anybody is interested
More information about the Devel