[IAEP] Sugar on Android via HTML5

[Caryl Bigenho]

Hi Folks…


Here is a link to an interesting interview, from today's USA today, with Apple's Jony Ive and Craig Federighi where they discuss how they approach design. I think there is something to be learned here.  http://www.usatoday.com/story/tech/2013/09/19/apple-jony-ive-craig-federighi/2834575/


I especially like this quote, actually from Robert Brunner, Apple's director of industrial design from 1989 to 1997 (who was the one that found and hired Ive), "Apple, (is) one of those few companies you can count on one hand that are fully design-focused. They start with the user's experience first, and drive back through their infrastructure to make that a reality."


So, why not "think like Apple" when designing the Android/Sugar experience?


I like the way this discussion has been going because it seems to be headed in the direction of focusing on the user experience.  


Caryl


P.S. The "Dream Screen" seems to have one big problem, as I see it. You can remove or hide apps you don't feel are appropriate for your child (or crash too often, or lack educational value), but I have yet to find a way to add other more appropriate apps to the mix. I sent a request to their help department, but so far have been ignored. They can be downloaded to the Android side, but how to get them to the child's "Dream Screen," a mystery so far.
From: sverma at sfsu.edu
Date: Thu, 19 Sep 2013 06:56:39 -0700
Subject: Re: [IAEP] Sugar on Android via HTML5
To: wad at laptop.org
CC: cbigenho at hotmail.com; iaep at lists.sugarlabs.org; devel at lists.laptop.org; donna at laptop.org



On Thu, Sep 12, 2013 at 4:54 PM, John Watlington <wad at laptop.org> wrote:



On Sep 10, 2013, at 5:04 PM, Sameer Verma wrote:


On Thu, Sep 5, 2013 at 7:51 PM, Caryl Bigenho <cbigenho at hotmail.com> wrote:







One of the things that makes Sugar the ideal learning platform for children (and youth) is the wonderful compatibility of so many of the Activities ... both from Activity to Activity and from student to student. This facilitates the sort of learning we are all hoping to see more of... creative problem solving, project based learning and cooperative learning. Without this ability to integrate parts of projects, it would just be another collection of apps.



I did not want to muddy the picture by injecting my own viewpoint, but now that I've heard from others (on and off list) it is clear that the split is driven by the role they play in the ecosystem. 


Most technologists have come up with reasons why they don't think a complete Sugar experience would work on Android. Therefore, activities must run like any other app on Android. On the other hand, as Caryl said, "Without this ability to integrate...it would just be a collection of apps". 




Somewhat knowing the limitations of what can be done with Sugar stuff on Android, but disregarding that for a minute, I would say that Sugar as a *platform* is an experience. It has a UI. It has a UX. Everything from the Zoom interface to the activities to the Journal is Sugar. We have taken the original "Sugar on the OLPC XO" experience and replicated that to the classmate PC, SoaS, and other spins and distros, but in none of these cases did we break the holistic Sugar experience. Now, along comes a popular OS, and because the tech parts don't fit, we are advocating breaking up the pieces and taking whatever flies. Memorize will become one of the few hundred thousand apps on Android.





I disagree. 

It's like saying we'll do the cat sprite from Scratch, but nothing else. It's like saying we'll do the birds and pigs from Angry Birds, but not the slingshot. Sugar, without all its pieces isn't worth the trouble.


Sameer,   I disagree somewhat with your thesis (and am very glad you started this discussion.)



Disagreement is good. It brings out perspectives :-)
 


>From a technological standpoint, it is actually probably easier to implement what you describe:Sugar as a monolithic Android application, which takes over the entire user interface when

launched.   The reason I never considered it seriously was the larger ecosystem.
The reason to move to Android from Linux is two-fold:- Chip vendors are dropping Linux support in favor of Android.   The cheap chinese ARM

 vendors only support Android.- Android/iOS are where application development is happening.  There is a much largercommunity of Android developers than Linux or Sugar developers.


The hope was to provide the infrastructure underlying Sugar (the Journal datastore andcollaboration) as Android services, encouraging their use in new Android applications.In this model, the Journal is another Android application, accessing the Journal datastore service.

New Sugar activities written in HTML should be capable of running in Sugar on Linuxor as Android activities (although perhaps with different execution wrappers).In this manner, perhaps we can enlarge the Sugar community with developers mainly

targeting Android.   If we pursue Sugar as a single Android application, with embeddedPython activities, we are isolating ourselves from the Android community.




I see your point. It's clearer now that the concepts of Sugar should be pushed into Android (or any other platform for that matter). 

 


The danger of this approach is the loss of an integrated UX.  This could be addressedby customizing the home UI, in the same manner that the XO tablet has a custom home UI

implementing the Dreams interface, but that would require "rooting" the tablet in some manner.But the native Android UI isn't that bad...



Let me expand on this point. There may be room for an "and" instead of an "either/or". 

Most of my research is on the user perspective of software, as opposed to the developer perspective. Users who are far removed from the developer bits tend to make adoption decisions based on *perceived* attributes as opposed to the real ones. So, instead of looking at APIs, protocols, code, they tend to look at things like relative advantages, compatibility with work environment, ease-of-use, voluntariness, etc. (See https://en.wikipedia.org/wiki/Diffusion_of_innovations#Rogers.E2.80.99_5_Factors)



Now, in schools, the "voluntariness" will be low, in that the school/education system dictates what needs to be used in the classroom. However, when the machine goes home, "voluntariness" will kick in. If they have been using Sugar in the past, "compatibility" will kick in, and so on. 



So, to ease a transition, even if the developer bits are entirely different, a similar UI and UX will usually improve adoption. MacOSX went to a BSD base, while maintaining a similar UI from OS9. When Microsoft introduced NT, it's core was entirely different, but they maintained a similar UI. In fact, a major break in the UI (and therefore UX) as in the case of Win8 has created significant problems (bring back the Start button). In another world, the New VW Beetle kinda looks like the old VW Beetle. Internally, they are nothing alike, but it sells well on the fondness factor of the days gone by. 



If we can use the approach used in the "Dreams" UI to create a skin, a look and feel of the Sugar UI,

AND

bring in collaboration, datastore, etc as you had suggested earlier, 



then the problem of rebooting from one OS to the other goes away. It will be finger swipe to go from Sugar to full Android (and maybe even to Dreams).

This still does not address the issue of what happens to the apps that live outside of this "Sugar UI", but would still like to take advantage of the datastore, collaboration, etc. It's analogous to how we don't have TurtleArt icon in GNOME, but can run it if needed, and how we have the "Documents" folder as a go-between from Sugar Journal to GNOME.



This is a rich space. More conversations please! (Apologies for not writing back earlier).


cheers,
Sameer 



Cheers,wad


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/iaep/attachments/20130919/9ad0767a/attachment.html>