On 13 April 2013 03:21, <<a href="mailto:forster@ozonline.com.au" target="_blank">forster@ozonline.com.au</a>> wrote: <div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I would like to see all these questions discussed further. I would like the technical implementation discussions to be more contextualised in terms of user experience. </blockquote><div> Hi Tony, let me try contextualize, for what I know so far. I think these are the possible technical approaches to Sugar on Android (I'm going to simplify a lot, so this is not going to be exactly accurate). 1 Android kernel + Ported linux libraries + Sugar 2 Android kernel + Datastore/Collaboration replacement + Sugar rewritten in HTML 3 Full Android + Datastore/Collaboration replacement + Sugar activities rewritten in HTML 4 Full Android + Datastore/Collaboration replacement + Sugar activities rewritten with native Android API In terms of UX, 1 has only one major consequence. It will not possible to run Android and Sugar apps side by side. The rest would stay all the same. That would be the main consequence for 2 as well. Other small modifications might be required, for example the single instance stuff that started this thread. The change of toolkit will certainly have some consequences on the activities people will write, hard to predict but I'm hoping in a positive direction. I'd say html is much richer than gtk. So I'd say with 1 and 2 the goal is to keep pretty much the same user experience (although I think we should consider improvements while we are rewriting things). That's why the discussion so far has not been including UX considerations. Where UX would be interesting is with 3 and 4, as your questions shows. As far as I know these have not been researched much, or at least not discussed in detail on the mailing lists. I'm personally not very interested in them because I feel they would produce a bit of a UX monster and we would risk to lose what makes Sugar a compelling proposition (as described by Bert). Doing 2 would make it much easier to run Sugar activities on full Android, even if maybe with reduced functionality, and I would contempt with that. Anyway, I do think 3 and 4 are worth investigating, I'm just not going to do it myself. </div></div>