[Sugar-devel] conversations about sugar ui design

[mokurai at earthtreasury.org]

On Sun, August 19, 2012 11:56 pm, David Brown wrote:
> 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.

The illiterate, including pre-schoolers, are a core part of our target
audience. We have two-year olds using our Record activity to take
photographs and present slide shows. Making words the primary UI element
would only complicate matters for them.

We also use icons in order not to have to localize all of our names into
more than 100 languages, specifically to support users in languages where
localization is incomplete, or not even started.

>  icons would be effective if they were
> universally obvious a priori, but that is not possible -

Icons do not have to be obvious or "intuitive". They only have to be
memorable enough so that they don't have to be explained twice. Of the
icons I have on my Sugar desktop in Ubuntu, only Abacus and TamTamMini
appear in any way obvious to me: pictures of an abacus and of musical
instruments. But they will not be obvious to little children who have not
seen an abacus or Western band instruments, and they do not convey the
fact that we have a multi-base abacus and a General Midi music program
with full Midi editor that supports collaborative performance over the
network. However, the names of the activities are no more obvious except
to those who have some experience of writing, painting, browsing, and so
on.

> 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.

We have found otherwise in many of our projects, particularly the one for
completely illiterate villages. You might as well say that children should
not be expected to learn the names and behaviors of things without having
name labels stuck on them. We evolved to be able to learn thousands of
names for things we see, not to read labels.

>  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.

Already implemented. Have you examined the Sugar Control Panel? Also, have
you read our Human Interface Guidelines?

http://wiki.sugarlabs.org/go/Human_Interface_Guidelines

Of  course, an option to toggle between icons and the user's language
could be helpful in addition to being able to get the name for any icon by
hovering or right-clicking. Then the icons would remain available to the
illiterate and to those whose mother tongue is not supported, and to those
who prefer them. (This is a major feature in, for example, the Mac UI,
which gives a choice of icons, names, or both.) For example, Ethnologue
lists 79 languages used in Ghana, of which Akan Twi has the  greatest
number of speakers, with 8 million out of a population of 22 million.
However, the official language and the language of instruction in the
schools is English, which is a third language for most students. Nigeria
has more than 500 languages, and India more than 800.

> 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.

Not so, and most illogical. Sugar users do not learn Logo before Turtle
Art. Logo is not even provided in Sugar, although it is available to
download. You click a turtle icon, you get a turtle right in the middle of
the screen, with a bunch of tiles that you can try out, and a library of
programs that make pictures.

TA can be made familiar to preschoolers using my lesson schema, You Be the
Turtle, which does not use the computer at all.

http://wiki.sugarlabs.org/go/Activities/TurtleArt/Tutorials/You_be_the_Turtle

> 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.

We have not found this to be an issue. Etoys or Scratch would be better
examples for your point, where neither the icon nor the name is
explanatory. But it doesn't matter. Children are not put off by an
impenetrable icon or name. They click, and see what it does, and then they
know what the icon or name is for the next time. Both Turtle Art and The
Etoys Tutorials are highly discoverable at the elementary level, as are
almost all Sugar activities, apart from the question of collaboration. But
you don't have to show the children collaboration twice.

Many children in our target audience have not seen a paintbrush. But after
the first year of any deployment, the children being given XOs for the
first time will already be familiar with them from looking over the
shoulders of older children, or occasionally borrowing an XO to try out.
This principle was clearly established in the Hole in the Wall Computer
experiment, where every child who discovered how something worked showed
the rest of the group.

> with 69 apps already mooted (and presumably a thousand more waiting to
> be added),

Maybe 700 now available in the Activities repository, and many thousand to
come.

> 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")

Done in the search engine at http://activities.sugarlabs.org/

> 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.

Tree-structured access, as in Gopher, is a disaster, which is why there
are so few remaining Gopher servers. You are trying to solve a problem
that does not exist. We start with a modest selection of activities on the
home screen, and leave it to the children which to add or remove using the
Favorite buttons in the Activities List view, and at
activities.sugarlabs.org. We also let the children group their icons as
they see fit. They are not tethered to the ring in later releases of
Sugar.

> <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.>

Tabs have already been implemented. We have been over this ground. The
screen is too small for doubling the toolbar size.

> 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).

NO MOUSE. Trackpad, until we get a gesture interface on a touch screen.
Governments will not thank you for adding expense and complication to
their deployments.

> <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.

Every system requires detective work to get started (and again for those
who wish to go beyond what is documented). But then users have options to
put things where they want them. Not an issue.

> <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

There is no either-or here, and nothing about it is mere. I have
previously suggested that you get down off your high horse, because I find
your attitude of superiority mildly offensive.

Among the objectives are to facilitate learning and collaboration,
including learning and use of sharp tools, access to information and
ideas, and access to other people.

Computer literacy is a failed idea, in the same sense as having a room
full of books, paper, and pencils, to which students are admitted for an
hour a week, without any opportunity to use what they learn in class, for
homework, or for personal projects. Real literacy comes from reading and
writing constantly, and from discussing what one reads and writes with
others constantly, or using the written word in practical matters such as
grocery shopping or software architecture. Sugar literacy in this latter
full sense is one of the aims of our project, but only as a means to much
greater ends, starting with getting children ready to take on and create
jobs and thereby to put an end to poverty and its many attendant ills.

We have made Sugar as transparent as we know how, consistent with keeping
it as powerful as we can make it. Leaving out the words unless the child
asks for them (by hovering with the cursor) is one of the ways we do that.

> <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"

That is not what the Journal does, and certainly not what it is for. Work
sessions are saved automatically when the student quits them. Naming and
commenting sessions is optional.

> 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.

Done. Have you actually tried it?

> 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"

Clearly not so. This list demonstrates beyond all doubt that you remember
how to be offensive and idiotic.

> and here is a partial list of things that i wish i had been taught at the
> time:
>
> 1. why some kids become bullies

I recommend the little book You Can't Say You Can't Play, by Vivian Gussin
Paley. It does not stop at asking why children who are fearful lash out,
but rather, what can we do to prevent it, and what sort of obstacles the
cure faces.

> 2. why some teachers become bullies

Paley is still the best resource I know. I had a mildly bullying teacher
who was angry at having to teach in a high school rather than a
university. Fear and anger seem to sum it up. Some people are more
susceptible than others.

> 3. the cost of living

The Theory of the Leisure Class, by Thorstein Veblen, and The Wealth of
Nations, by Adam Smith, who was in no way the apostle of Ayn Rand
Laissez-Faire that Market Fundamentalists make him out to be. Also This
Time Is Different: Eight Centuries of Financial Folly, by Carmen M.
Reinhart and Kenneth Rogoff

> 4. what girls want

They don't know themselves, any more than boys do. See Emma, and Sense and
Sensibility, both by Jane Austen. There are some decent movie versions and
adaptations, including Clueless.

> 5. why my parents want me to do this or that

See Darwin, The Descent of Man, and Veblen again. They vainly seek
immortality by fashioning you in their image, or in some cases they try to
make you into what they would have preferred to be instead.

> 6. how to repair a bicycle

I use Everybody's Bike Book, but there are many others.

Being able to learn things yourself, without waiting for a teacher, and
being able to find what to learn from, is of the essence of the OLPC/Sugar
program.

You ask easy questions, for which answers of a sort already exist. I am
interested in much harder ones, such as what the next version of physics
or economics or democratic republics might look like. I am very much
looking forward to what up to a billion children at a time can come up
with together, although at my age I will get to see only a little of it.

> 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

Yes, we are working on localized health textbooks, and many NGOs are
working on clean water, decent food, health care delivery, and better
information. Check out Partners in Health.

> <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.

We are aware of all that, which is a feature of all social network sites I
have examined. At some point, we need a child-friendly social network
protected from predatory adults. Right now, governments mostly keep their
school networks tightly locked down, so that it is hard to share from one
school to the next.

>> 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!).

See Moodle.

> developers would need a whole different interface -
> maybe xubuntu or somesuch??

The version of Linux does not matter for development. Integrated
Development Environments and repositories matter. Take a look at

Gitorious http://git.sugarlabs.org/

SqueakSource3 http://ss3.gemstone.com/ss/

FLOSS Manuals Write http://booki.flossmanuals.net/

Replacing Textbooks http://booki.treehouse.su/

Sugar Labs Localization http://translate.sugarlabs.org/

Idle is one of the commonly used Free Python IDEs. Squeak comes with its
own. There are others. Many editors have syntax modes for dozens of
widely-used languages.

>> 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

There we agree.

> <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.

Distribution to national school systems is in the hands of the governments
concerned. Distribution to pilots is in the hands of the government
agencies and NGOs concerned. The problem is not physical distribution, but
organizational will.

> 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).

Dual boot with XP was tried on XOs, and XP failed. We have Gnome on recent
XOs accessible without a reboot.

> 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

I see that it has moved to
http://wiki.sugarlabs.org/go/Talk:Design_Team/Proposals

You do have some interesting ideas, such as a partly spoken UI.

I should mention that we have done some work toward making XOs be able to
speak any text in any language, including UI text. We have also discussed
text coloring, as used in karaoke, so that the child can follow along in a
text as it is read, thereby being aided in learning to read. This
technique, as used in Same Language Subtitling of Bollywood movies, has
been surprisingly effective with adult audiences in India.

> 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.

Generally not a problem, and we can easily revert any such wiki damage.

> david
> --
> website <http://sites.google.com/site/djhbrown2/home>
> +61(0)266537638
> +61(0)488471949
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>


-- 
Edward Mokurai
(默雷/निशब्दगर्ज/نشبدگرج)
Cherlin
Silent Thunder is my name, and Children are my nation.
The Cosmos is my dwelling place, the Truth my destination.
http://wiki.sugarlabs.org/go/Replacing_Textbooks