Re: [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,
shall be a great opportunity for us to start testing, measuring and
learning important things.


2012/8/26 

> On Sun, August 19, 2012 11:56 pm, David Brown wrote:
> > this note embraces several different emails from >Aleksey and 
> >
> >> 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/T

Re: [Sugar-devel] conversations about sugar ui design

[mokurai]

On Sun, August 19, 2012 11:56 pm, David Brown wrote:
> this note embraces several different emails from >Aleksey and 
>
>> 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 

Re: [Sugar-devel] conversations about sugar ui design

[Aleksey Lim]

On Mon, Aug 20, 2012 at 09:09:57AM -0400, Walter Bender wrote:
> On Sun, Aug 19, 2012 at 11:56 PM, David Brown  wrote:
> > ...
> > 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.
> 
> As regard the activity icons on the home page (as several people have
> responded already) we haven't observed this as being a major problem
> with Sugar in the field. Also, at least in the beginning, we were
> disciplined about naming activities as actions, e.g., Paint, Browse,
> etc. Turtle Art was a bit of an exception and probably could have been
> named Program.

Keeping activity names consistent sounds too over centralized for
dispersed community on SL level. But I think it will be useful if
UI will present two id elements for one activity (somehow, not exactly
two labels for one activity item). When the first one will be a
functional name, e.g., "Paint" (despite of presence Paint activity, it
might be, e.g., TuxPaint) that can be tweaked on distribution level
(different distributors might follow different naming schemes assuming
the targeting audience).

On ASLO, this feature is implemented by categories and tags. But for
desktop application (which is different to ASLO because clicking
assumes immediate launch) it might be useful to implement this feature
a bit different. For example, having functional abstraction level
in addition to activities one. Users might run activities directly
from functional level but can switch to direct activities (and select
what particular activity will represent "Paint" function).

> It has been oft observed that children will push buttons in order to
> find out what they do, as oppose to adults, who like to know what
> buttons do before they push them.
> 
> In general, there are roll-over text hints for every icon in Sugar.
> We've had a long (4+ years) argument about the length of the delay in
> revealing those texts and in the most recent Sugar, all secondary
> palettes will appear immediately.

Functional level will be useful not only for newcomers when people don't
know what TurtleArt does, but also for simplification users experience.

-- 
Aleksey
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] conversations about sugar ui design

[Sebastian Silva]

"We have an opportunity in Peru to do some experiments." - WB

Hi David,
As a member of the Somos Azucar research & development team and direct
responsible for the software distribution prototypes to be piloted in
Peru, I warmly welcome your constructive offer of help.
We (Laura and I) are responsible for the Sugar Network sketches presented
to you by Aleksey, who is doing the back-end implementation to support 
specific functionality.

It is important to underline that the Sugar Network client (webui) is an 
experimental intervention that hopes to facilitate knowledge exchange
within an initial environment (Sugar and Sugar Activities in Perú).
Of course, there are a wide set of constraints (**).

You can find more information about the Sugar Network project as it is
being implemented for Perú at: http://pe.sugarlabs.org/go/Red_Az%C3%BAcar

Specific goals of the system are: to provide a de-centralized network for 
feedback, support and learning resources exchange and distribution.

The current UI implementation is expected to evolve quickly and our
goal is to have a 1.0 release by December 2012 with main functionality.

The UI dev strategy has been to rely on standard HTML+CSS+JS in order to 
facilitate rapid UI experimentation by the widest possible group of people 
including ourselves.

So far we've sought to directly expose functionality, trying to follow 
Sugar's UI style and paradigms of simplicity, reflection and collaboration.
However we are at a stage of reflection into how to better expose 
functionality to reflect the system's stated goals to the local community.

As for a design forum, Sugar Network is hoped to become such a forum where
feedback can be collected with the purpose of improving specific system
components (for example, Sugar itself). Your feedback / proposals for improving
the Sugar Network experience are welcome and will be taken into consideration.

I recommend installing Sugar Network locally from the sweets-desktop packages
for you to be able to explore functionality specific to Sugar.
Regards,
Sebastian

(**) most notable constraints in no particular order:
- (almost) no connectivity
- slow hardware / crappy touchpads
- language/cultural barrier
- remote locations
- not skilled deployment personnel
- disreputed laptop project
- conflicted national education system


On Mon, 20 Aug 2012 13:56:39 +1000
David Brown  wrote:

> this note embraces several different emails from >Aleksey and 
> 
> > 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.
> 
-- 
Sebastian Silva 
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] conversations about sugar ui design

[Walter Bender]

On Sun, Aug 19, 2012 at 11:56 PM, David Brown  wrote:
> this note embraces several different emails from >Aleksey and 
>
>> 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.

As regard the activity icons on the home page (as several people have
responded already) we haven't observed this as being a major problem
with Sugar in the field. Also, at least in the beginning, we were
disciplined about naming activities as actions, e.g., Paint, Browse,
etc. Turtle Art was a bit of an exception and probably could have been
named Program.

It has been oft observed that children will push buttons in order to
find out what they do, as oppose to adults, who like to know what
buttons do before they push them.

In general, there are roll-over text hints for every icon in Sugar.
We've had a long (4+ years) argument about the length of the delay in
revealing those texts and in the most recent Sugar, all secondary
palettes will appear immediately.

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

We had extensive use of scrolling in earlier versions of Sugar and
found that it was not readily discoverable, even by curious kids.
Maybe it was simply a matter of poor design and it certainly could be
revisited.

Another argument against scrolling is that it requires you to remember
where things are. Not sure that is necessary.

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

Agreed. But as per above, kids seem to engage in such detective work
anyway. In a recent study in Ethiopia, it was reported that kids
explored thousands of activities per month. This was all done through
clicking on icons (Android in this case) to see what they do.

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

Apparently I was not clear. Let me explain by example.

Sugar has a Record activity used to record still images, sound, and video.
Sugar also has a Write activity, used to write texts.
When you use Record, your recordings are saved to the Journal.
When you use Write, you can import recording from the Jou

Re: [Sugar-devel] conversations about sugar ui design

[Aleksey Lim]

On Mon, Aug 20, 2012 at 01:56:39PM +1000, David Brown wrote:
> this note embraces several different emails from >Aleksey and 
> 
> > 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...)

More practical thoughts.

Unfortunately, Sugar Labs community is not overcrowded by designers and
usability specialists (though, some people think that such overcrowding
is not good for Gnome:). And, not all projects started within the Sugar
Labs (Sugar Network is a recent effort) have rapt attention from UI and
edu people. Laura and Sebastian (people who work on Sugar Network webui)
do some efforts to involve people from Peruvian community, but afaik,
there are no more people who can work on webui on regular basis.

You posted some UI notes, if you want, we can work on Sugar Network UI
in more practical way. (/me is waiting a response from Laura and
Sebastian here).

-- 
Aleksey
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] conversations about sugar ui design

[Aleksey Lim]

On Mon, Aug 20, 2012 at 01:56:39PM +1000, David Brown wrote:
> this note embraces several different emails from >Aleksey and 
> 
>  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

A couple of general thoughts.

My own background, when I started contributing to Sugar Labs, was that
I didn't see how Sugar Shell might be particular useful in educational
process (but I saw technical potency of having community of "doers"
targeted to learning platform, whatever it might be at the end).
At the same time, Sugar Shell has OLPC roots when OLPC needed, in my
mind, "desktop" environment for XO laptops. And, Sugar Shell is much
better, imho, option than regular desktops existed in the past and
present right now.

I mean, attempt to create entire desktop environment should not be
dominant effort on Sugar Labs level when there is no urgent need in
having desktop environment (different to "office" desktops) to install
on particular hardware. Obviously, high aged students, most likely,
will prefer not Sugar Shell as a regular desktop environment. Low aged
students, at least in my mind, don't exactly need desktop environment,
but rather some environment (maybe pretty isolated from the rest of
current desktop) that will be useful for them from teacher's pov.

In other words, it will be useful if software, created within the Sugar
Labs, will run on regular desktops to give more flexibility for people
in the field. For example, particular school/region might decide to
spread tablets on Android among students. The "lets port Sugar [as a
desktop environment] on Android" sounds scary for me. Much better if
there will be a way to launch some Sugar activities as a regular Android
apps and having a kind of shell (most likely created from scratch to
make it more Android) for cases when students [low aged] need
limited/restricted environment.

-- 
Aleksey
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel