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. 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. <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.> 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). <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. <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 <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" 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. 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" and here is a partial list of things that i wish i had been taught at the time: 1. why some kids become bullies 2. why some teachers become bullies 3. the cost of living 4. what girls want 5. why my parents want me to do this or that 6. how to repair a bicycle 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 <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. > 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!). developers would need a whole different interface - maybe xubuntu or somesuch?? > 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 <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. 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). 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 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. 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