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 <a href="http://pe.sugarlabs.org/go/Red_Az%C3%BAcar">Red Azúcar</a>, shall be a great opportunity for us to start testing, measuring and learning important things. <div class="gmail_quote">2012/8/26 <<a href="mailto:mokurai@earthtreasury.org" target="_blank">mokurai@earthtreasury.org</a>> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>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 <a href="http://network-testing.sugarlabs.org" target="_blank">http://network-testing.sugarlabs.org</a> >> 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. </div>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. <div> > icons would be effective if they were > universally obvious a priori, but that is not possible - </div>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. <div> > 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. </div>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. <div> > 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. </div>Already implemented. Have you examined the Sugar Control Panel? Also, have you read our Human Interface Guidelines? <a href="http://wiki.sugarlabs.org/go/Human_Interface_Guidelines" target="_blank">http://wiki.sugarlabs.org/go/Human_Interface_Guidelines</a> 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. <div> > 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. </div>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. <a href="http://wiki.sugarlabs.org/go/Activities/TurtleArt/Tutorials/You_be_the_Turtle" target="_blank">http://wiki.sugarlabs.org/go/Activities/TurtleArt/Tutorials/You_be_the_Turtle</a> <div> > 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. </div>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. <div> > with 69 apps already mooted (and presumably a thousand more waiting to > be added), </div>Maybe 700 now available in the Activities repository, and many thousand to come. <div> > 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") </div>Done in the search engine at <a href="http://activities.sugarlabs.org/" target="_blank">http://activities.sugarlabs.org/</a> <div> > 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. </div>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 <a href="http://activities.sugarlabs.org" target="_blank">activities.sugarlabs.org</a>. We also let the children group their icons as they see fit. They are not tethered to the ring in later releases of Sugar. <div> > <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.> </div>Tabs have already been implemented. We have been over this ground. The screen is too small for doubling the toolbar size. <div> > 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). </div>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. <div> > <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. </div>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. <div> > <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 </div>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. <div> > <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" </div>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. <div> > 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. </div>Done. Have you actually tried it? <div> > 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" </div>Clearly not so. This list demonstrates beyond all doubt that you remember how to be offensive and idiotic. <div> > and here is a partial list of things that i wish i had been taught at the > time: > > 1. why some kids become bullies </div>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. <div> > 2. why some teachers become bullies </div>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. <div> > 3. the cost of living </div>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. <div> > 5. why my parents want me to do this or that </div>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. <div> > 6. how to repair a bicycle </div>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. <div> > 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 </div>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. <div> > <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. </div>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. <div> >> 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!). </div>See Moodle. <div> > developers would need a whole different interface - > maybe xubuntu or somesuch?? </div>The version of Linux does not matter for development. Integrated Development Environments and repositories matter. Take a look at Gitorious <a href="http://git.sugarlabs.org/" target="_blank">http://git.sugarlabs.org/</a> SqueakSource3 <a href="http://ss3.gemstone.com/ss/" target="_blank">http://ss3.gemstone.com/ss/</a> FLOSS Manuals Write <a href="http://booki.flossmanuals.net/" target="_blank">http://booki.flossmanuals.net/</a> Replacing Textbooks <a href="http://booki.treehouse.su/" target="_blank">http://booki.treehouse.su/</a> Sugar Labs Localization <a href="http://translate.sugarlabs.org/" target="_blank">http://translate.sugarlabs.org/</a> 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. <div> >> 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 </div>There we agree. <div> > <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. </div>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. <div> > 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). </div>Dual boot with XP was tried on XOs, and XP failed. We have Gnome on recent XOs accessible without a reboot. <div> > 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: > <a href="http://wiki.sugarlabs.org/go/Talk:Design_Team/Proposals/Home_View" target="_blank">http://wiki.sugarlabs.org/go/Talk:Design_Team/Proposals/Home_View</a> </div>I see that it has moved to <a href="http://wiki.sugarlabs.org/go/Talk:Design_Team/Proposals" target="_blank">http://wiki.sugarlabs.org/go/Talk:Design_Team/Proposals</a> 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. <div> > 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. </div>Generally not a problem, and we can easily revert any such wiki damage. <div> > david > -- > website <<a href="http://sites.google.com/site/djhbrown2/home" target="_blank">http://sites.google.com/site/djhbrown2/home</a>> > <a href="tel:%2B61%280%29266537638" value="+61266537638" target="_blank">+61(0)266537638</a> > <a href="tel:%2B61%280%29488471949" value="+61488471949" target="_blank">+61(0)488471949</a> </div>> _______________________________________________ > Sugar-devel mailing list > <a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a> > <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a> > -- Edward Mokurai (默雷/निशब्दगर्ज/نشبدگرج) Cherlin Silent Thunder is my name, and Children are my nation. The Cosmos is my dwelling place, the Truth my destination. <a href="http://wiki.sugarlabs.org/go/Replacing_Textbooks" target="_blank">http://wiki.sugarlabs.org/go/Replacing_Textbooks</a> </blockquote></div> -- Laura V. I&D SomosAZUCAR.Org Skype acaire IRC kaametza