[Sugar-devel] conversations about sugar ui design

[Laura Vargas]

We have chosen to test a mixed scenario for main navigation that includes
both *icons* and *words*.

I personally believe that by using both communication elements, we will
increase our changes of been able to successfully *communicate* with a
larger number of participants.

Here at South América, there are many scenarios that would be a good idea
to measure in order to obtain reasonable amount of data to make reasonable
conclusions and according adjustments.

The upcoming software update in Perú [2013], which will also be launching
Sugar Network locally named Red
Azúcar<http://pe.sugarlabs.org/go/Red_Az%C3%BAcar>,
shall be a great opportunity for us to start testing, measuring and
learning important things.


2012/8/26 <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
>
>
>


-- 
Laura V.
I&D SomosAZUCAR.Org

Skype acaire
IRC kaametza
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20120827/5666b5eb/attachment-0001.html>