[Sugar-devel] Activity Central's Sugar related priorities.

[NoiseEHC]

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?
1. A HTML5 + JavaScript activity model called Sugar Web Activity, which 
reaches 2-3 million children? (lets call it SWA)
2. A HTML5 + JavaScript activity model called HTML5 + JavaScript, which 
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...
https://developers.google.com/drive/about-auth

2. Datastore. There is no way to access the Google Drive if you cannot 
authenticate. I do not see why would anyone use a new JavaScript lib 
which accesses only the journal when they are already familiar with some 
WEB technology. Like WEBDAV or the OpenStack's SWIFT API.
http://docs.openstack.org/api/openstack-object-storage/1.0/content/storage-object-services.html
Or simply using POST for uploading:
https://developers.google.com/drive/manage-uploads

3. Collaboration. Using the Google Drive Realtime API is dead simple. It 
is the most missing feature from SWA BTW.
https://developers.google.com/drive/realtime/
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.
http://phonegap.com/

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 
relevant...)
http://lists.sugarlabs.org/archive/sugar-devel/2010-June/024589.html

Thank you for your attention!
Andrew

ps:
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 
record results.
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 
usability masterpiece...
5. Allow exporting projects (like "Growing a plant") automatically to 
share with others in WEB format.
Hmmm, good luck with this plan.

ps2:
I can share the C webkit activity code if anybody is interested 
finishing it...