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 <moku...@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@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
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel