[IAEP] [Marketing] OLPC rules out Windows for XO-3

C. Scott Ananian cscott at cscott.net
Thu Jun 3 13:45:47 EDT 2010


I strongly encourage the Sugar team to consider rethinking the Sugar
UI from the ground up for touch.  The "simple" port is likely to yield
a very unsatisfactory experience; "fat fingers" are just not precise
pointing devices, and a lot of gestures which seem intuitive for a
mouse don't really work for touch.  In the same vein, there are many
finger gestures which are intuitive which aren't being exploited in
the mouse-based UI.  And, of course, the whole "pop up a keyboard" to
type thing is weird now; keyboard shortcuts and special "home", "view
source", etc, keys don't work as well.  Everything needs a place on
screen.

My suggestion would be to first convene a "ground up rethink" of what
a touch-based Sugar could be.  Then, realizing that the best is the
enemy of the good and the realistic limits on Sugar development, draw
up a "from here to there" plan concentrating on grabbing the
lowest-hanging fruit first (perhaps a redesign of the home screen, or
rethinking palette menus, or whatever) and embarking on an incremental
strategy to adapt.

Software engineers like to think in terms of generalities, and "what
can we do that's not too hard", but I'm suggesting that's *not* the
most fruitful way to approach adaptation to touch.  The engineering
thinking should be *second*.  Design and user experience should be
first.  Every designer should probably be required to have spent
serious time with an iPhone or iPad or touchscreen phone (preferably
from a variety of different touch-based OSes) to be sure we're not
just mapping mouse onto touch.  Ideally, take some time to give an
iPad to a 3-6 yr old and watch and learn.  The result should be a
*book*, which describes the ideal UI.  That will be the long term
(think, next decade!) goals for Sugar.

I'd personally like to see the Sugar team come up with bold ideas that
go *beyond* what we're seeing in Android and iPhone OS; in particular,
how to best enable *content creation*.  We've always said we'd like to
see a movie editing application in Sugar.  Concentrating on what
Record or Etoys or TurtleArt might look like with a touch-based UI
would be bold thinking that would radically advance Sugar's mission.
What does it mean to have the entire environment written in Python, if
Python is clumsy and hard to use with a touch-based interface?  Maybe
the direct-manipulation model of Etoys is a more natural fit?  What
does "view source" mean in a touch-enabled world?

I look forward to exciting times and crazy great ideas!
  --scott

-- 
                         ( http://cscott.net/ )


More information about the IAEP mailing list