[Sugar-devel] conversations about sugar ui design

David Brown djhbrown at gmail.com
Sun Aug 19 23:56:39 EDT 2012


this note embraces several different emails from >Aleksey and <Walter>

> What you see on http://network-testing.sugarlabs.org
> is a first rough and implementation for webui,

you have put quite some effort into presenting your sketches, Aleksey:
whilst that is in itself impressive, i'm not keen on the sketches
themselves:  using icons instead of words is presumably an attempt to
make the ui accessible to the illiterate, but in my view it only
complicates matters.  icons would be effective if they were
universally obvious a priori, but that is not possible - icons have to
be learned just as do the symbols of any alphabet.  mother tongue is
preferable, as it contributes to the learning of literacy useful in
the broader context of the language world within which they live.  a
single release of a ui could have a feature that allows the ui to be
displayed in any of the languages that have been implemented.

the choices of names are developer-oriented rather than user-oriented:
for example, the name "turtle-art" makes sense only to people who are
already familiar with Logo.  Whereas, "draw a picture" (or its
translation) would make sense to any kid who can read her mother
tongue.  for those who can't read, a thumbnail of a half-finished
painting and a brush might work - it would take up more pixels than an
icon, but i don't think there should be many app-triggers on view at
the same time.

with 69 apps already mooted (and presumably a thousand more waiting to
be added), that creates a navigation issue which needs to be
addressed.  i feel that it could be done by creating categories of
activity (such as "learn", "play" and "meet") and subcategories etc,
making a simple tree structure (or maybe a network with cross-links).
the one thing i am sure of is that trying to put buttons for
everything on one screen creates information overload.

<I've been thinking for quite some time that we need a new approach to
the problem of toolbar items following off the end of the toolbar
.....A simple solution would be to double the vertical size of the
toolbar and wrap the icons onto a second row.>

perhaps there are too many tool buttons on screen at the same
time!.... - but in general, one way to display long lists of items is
to use scrolling, whether by mouse or finger slide - if the scrolled
list were an imaginary wheel viewed edge-on with, say, half a dozen
items in view at any one time, you wouldnt need a scrollbar, just a
single button to rotate it (or a wheel mouse, which i find quite handy
for scanning up and down lines of text).



<The model we have been using is one of "imagine and realize" and
"critique and reflect".>

sounds good but these are things that a kid would do within an
activity (aka app) - getting to that activity should not require
detective work.



<The Sugar learner engages in the cycle of
activities by using the Sugar tools as individual building blocks,>

ah.... if the objective were to produce sugar-literacy, that would
make sense, but if sugar were merely a tool to facilitate learning of
things that are going to be of use to the kid in the outside world,
then every effort should be made to make sugar itself as transparent
as possible, rather like google chrome tries to get out of the way
just as internet explorer tries to get in the way with thousands of
toolbars



<The Sugar Journal and Portfolio are the tools that tie things together,>

speaking as a child, i dont want to have to tediously write up "what i
learned today" since i am more focussed on the present and future than
on the (even immediate) past.  i would much rather my robot friend
remembered for me what i had done with it today so tomorrow i can pick
up from where i left off.  if i were using a paper workbook and a
crayon, everything i had written in it today would still be there
tomorrow so i wouldn't need to rewrite or precis it for my parents.

speaking as a former schoolchild (and having scanned the subtitles of
the Argentinian movie and agreeing with its points but being
disappointed by its lack of practical suggestion), here is the full
list of everything i remember i learned from my entire 12 years of
class-bound regimented schooling:
1. the chemistry teacher gives marks for tidy handwriting
2. robin hood had a bow that could shoot around corners
3. Miss Moss uses too much lipstick
4. the frog has a muscular penis
5. our history teacher was pretty
6. Shakespeare's porter at the gates of Hell was being lewd when he
says "that'll roast your goose"

and here is a partial list of things that i wish i had been taught at the time:

1. why some kids become bullies
2. why some teachers become bullies
3. the cost of living
4. what girls want
5. why my parents want me to do this or that
6. how to repair a bicycle

and one thing above all else that i wish kids in rural villages were taught:
small cuts develop into festering tropical ulcers unless they are
cleaned and protected from bacterial invasion


<while the neighborhood is where the group interaction occurs.>

collaborative activities could include friends from across the seas if
internet is available and learning/playing groups could be
self-forming.  Facebook has a "friend of friend suggestion" feature
that might be worth considering.


> Besides, Sugar Network itself, will be used not only by kids, but also
> by, e.g., teachers who will prepare content for students, developers who
> upload new Sugar activities, etc. Thus, Sugar Network will have several
> UIs for different purposes.

i think it makes good sense to have different uis for different
purposes; eg. teachers may want to maintain student progress records
that kids wouldnt need to see (indeed, shouldnt, if it's to be
non-competitive!). developers would need a whole different interface -
maybe xubuntu or somesuch??

> I've CCed people who are working on current webui implementation (that
> is intended to be piloted in several Peruvian schools). If you are have
> time, you can help to make UI more useful.

i'd like to try to assist/participate.  my first suggestion would be
to create a design forum so design discussions can flow and be
retained.  there is a design team meeting sometime soon, but i feel
that the design process should be basically asynchronous and ongoing -
one can't schedule one's brainwaves at just the right time during a
brainstrorming session (most of my better ideas occur to me when i am
on the toilet or thinking about something else or asleep...)


< Discoverability is important, but just one of many concerns.>

from a home base design point of view, i think discoverability is the
single most important issue of all: the job of a ui is to provide
discoverable access to what one can do with the thing


<The bad news is that while we can and do make many
unilateral changes, any major changes to the UI require building a
certain level of consensus in order to get our changes adopted. Alas,
there are many Sugar users still running our beta version from 2007.
Such is life in this business.>

new relases of uis could be distributed via the same physical
distribution channels that got the xos to the various groups in the
first place - on a usb stick on the back of a donkey if necessary.

a major change to "look and feel" requires user-testing in the field.
there is no reason why two different uis couldn't be available on the
same platform. (eg i have xp and xubuntu on an old laptop less
powerful than an xo; switching between them requires a reboot, but
that wouldnt be necessary for a multlface sugar ui as there would be a
common underlying implementation).

if anyone would like to join me in trying to come up with a design of
a more "obvious" alternative ui, here is a place where we could
share/coalesce ideas/designs:
http://wiki.sugarlabs.org/go/Talk:Design_Team/Proposals/Home_View
Being a wiki talk page, it offers the advantage that it is a communal
space that can be reworked so that it reflects current
thinking/concensus of its contributors and provide a platform for the
development and instantiation of conceptual design.  It also obviates
the need for participants to reiterate their views in ten different
conversations about the same thing and allows those views to be
modified/retracted since it is not a historical record.  hopefully it
wont get hacked.

david
--
website <http://sites.google.com/site/djhbrown2/home>
+61(0)266537638
+61(0)488471949


More information about the Sugar-devel mailing list