<html><body bgcolor="#FFFFFF"><div>On 16 Feb 2011, at 20:35, "C. Scott Ananian" <<a href="mailto:cscott@cscott.net">cscott@cscott.net</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div>On Wed, Feb 16, 2011 at 3:26 PM, Christian Bryant <span dir="ltr"><<a href="mailto:christianabryant@linux.com"><a href="mailto:christianabryant@linux.com">christianabryant@linux.com</a></a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I'm curious, is there a comprehensive requirements and/or design<br>
document for Sugar against which the recommendation is measured? I'd<br>
be curious to see a "gap analysis" that supports the argument to not<br>
use Python. If nothing else, I'd vote for a solid wiki page that can<br>
properly frame the idea, and the pros and cons.<br></blockquote><div><br></div><div>I would also be interested in seeing an thorough experience report from someone who has attempted to use Sugar on a touchscreen device. We already know that several major features (such as the frame and hover menus) fail completely.</div></div></div></blockquote><div><br></div><div>FWIW neither of those are particularly challenging design cases. The frame could be triggered by a hardware button, and the 'touch & hold' interaction will work just great for the hover menu case.</div><br><blockquote type="cite"><div><div class="gmail_quote"><div> Bert tested EToys on a touchscreen a few months ago and found lots of areas that needed work (search devel@ for that thread). </div></div></div></blockquote><div><br></div><div>As I remember, the issues Bert reported were not Sugar UI related, actually he mentioned the Sugar Activity toolbar design works well with it's large finger friendly buttons. It was the EToy object HUD that proved too small for easy finger use and in need of some design work for touch screens.</div><br><blockquote type="cite"><div><div class="gmail_quote"><div>Like you say, a comprehensive outline of the work required would certainly help give a realistic appraisal of the current "state of Sugar".</div>
<div><br></div><div>Or you could decide that Sugar-on-a-touchscreen just isn't interesting/isn't part of SugarLab's mission. That would put a big fork between Sugar's work and OLPC's work, since OLPC is committed (via its funding source) to producing a touchscreen machine in its next generation.</div></div></div></blockquote><div><br></div><div>Until OLPC is ready to provide contractors and some of the community with touch enabled sample hardware this is going to move quite slowly. I use an iPad running various VNC and RDP clients back to test VMs of Sugar, but most of the UI frustrations I hit are related to the VNC/RDP client interaction. I'm hoping some XO-1.75s with the custom touch screen layer will be enough to pick up some touch related dev momentum (once its dev cycle has settled down a little).</div><div><br></div><div>--Gary</div><br><blockquote type="cite"><div><div class="gmail_quote"><div> It then becomes even more important to have Sugar running well on non-OLPC hardware. Wiki pages detailing the progress of other "Sugar everywhere" efforts on non-OLPC machines would also help appraise the current state of the world. [These are much further advanced than Sugar-on-touchscreen, AFAIK, but I'm been assuming that SugarLabs doesn't want to allow itself to grow completely apart from the OLPC hardware effort. Perhaps my assumption is misguided.]</div>
<div> --scott</div><div><br></div></div>-- <br> ( <a href="http://cscott.net/"><a href="http://cscott.net/">http://cscott.net/</a></a> ) <br>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>IAEP -- It's An Education Project (not a laptop project!)</span><br><span><a href="mailto:IAEP@lists.sugarlabs.org">IAEP@lists.sugarlabs.org</a></span><br><span><a href="http://lists.sugarlabs.org/listinfo/iaep">http://lists.sugarlabs.org/listinfo/iaep</a></span></div></blockquote></body></html>