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

[Manuel Quiñones]

Hi NoiseEHC,

> 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.

Well we are trying to go in the direction you mention below, that is
standard web development.  So thanks for jumping in.

> 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...

Yes, option two... ideally.  We should tend to zero Sugar specific
functionallities.  I think it is a good compromise what we did: start
from simple web activities that already work side by side with GTK
ones, and tend to standard webapps.

> 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:

I think each of the following items deserve a thread on its own.  Feel
free to continue discussion.

> 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:

As far as I understand, Google Drive is an online service.  Please
note that we are targetting offline webapps, as Sugar is meant to work
without an Internet connection.  Of course it is not forbidden.  And
Drive could be a nice datastore backend.  But not the only one.

> 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

Daniel gave a good reply to this one.

> 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

Nice.  Reading about the WebDAV protocol and OpenStack SWIFT API.

> Or simply using POST for uploading:
> https://developers.google.com/drive/manage-uploads

Yeah, good point.

> 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/

Interesting.  It requires Internet.

> 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...

So, running and using those servers is what we need to research.

> 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...
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel



-- 
.. manuq ..