[Sugar-devel] [DESIGN] search toolbar in Group view
Hi, to have the same functionality in the Views, I would like to add a search toolbar to the Group View. That is trivial in the first place and code can be shared from the Mesh and the Group View. One thing that is a bit tricky to handle is that we use already grey icons to show that a buddy is absent at the moment. This collides a bit with the alpha representation when we do search. Is there some smart way to make that more distinguishable? I know we talked once about a different search mechanism all together but maybe there is something we can do short term. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Design] On Screen Keyboard – part of the 'get Sugar touch ready' feature set
Hi Chris, On 23 Aug 2012, at 19:45, Chris Leonard cjlhomeaddr...@gmail.com wrote: On Thu, Aug 23, 2012 at 11:10 AM, Gary Martin garycmar...@googlemail.com wrote: I like the most recent version well enough, http://wiki.sugarlabs.org/go/File:Maliit_Sugar_theme_work_13.png High praise ;) Improvements/changes? Sorry, I did not mean to damn with faint praise, it is really good work under very tight restrictions. I personally find the XO physical kb limiting, so I bought a rollable rubber USB kb :-) I am sincerely excited about the potential for an OSK in the realm of limitless i18n/L10n freed from the shackles of silkscreening. I'm a little concerned that the absence of the Home/Friends/Neighborhood/World quartet of XO specific keys will be missed, but I understand that it is tough to collapse 6 rows of XO keys into 4 rows for Maliit. Yes space is at a premium using an OSK [1], however as the OSK is only visible when a text input widget has focus, we need to make sure Neighborhood/Group/Home/Activity/Journal are accessible at all other times as well, primarily by improving touch access to the Frame (and improving Frame discovery, though unlikely for this cycle). Yes, the ergonomics of frame invocation/dismissal and switching focus from kb to other touch input needs deep thought, but I have confidence in the people smarter in UI design than I am that will be working on it. :-). I don't expect it to be tuned to re-training fossils like me, but at the agile minds and fingers of kids. I've got lots of other questions, but they are more i18n related, so I'll forego inserting them into this design thread, No, bring them up here if they are OSK related! Ok, you asked for it :-) Is there currently a mechanism for re-creating the many xkb-based layouts already designed for OLPC that never got silkscreened? http://wiki.laptop.org/go/Keyboard_layouts No, those are physical layouts not designed for OSK. There about 40 existing maliit layouts that I'll update to match our OSK design modifications. And then I'd imagine we will want to closely check the OSK layouts for the languages we prioritise, and make sure they cover our needs (the existing OLPC layouts will be a useful reference). Getting the existing OLPC xkb designs recreated is going to be pretty important once the existing Maliit layouts are adapted. It's also going to be a repetitive task (see attached spreadsheet), I'm wondering if there are hackerish methods for assisting in that task (scripts, spreadsheet templates, etc.)? Even the list of OLPC xkb layouts in my spreadsheet is incomplete, for example, I know of a layout for an Inuktitut variant that Walter helped some Canadians design. Generating some local documentation on de novo Maliit keyboard design is going to pretty important as I can easily imagine getting asked a lot of questions about this that can no longer be put off with, well, first you make a silkscreen in a factory in China. . . I'd love to be able to do more for new languages than say go look at https://wiki.maliit.org/Documentation and let me know when you've figured out their process. Sugar Labs is, by it's nature, an entry point for languages under-represented in ICT and we already do a lot of stuff (like glibc locale design assistance) in support of these language communities. Language switching: So, with the language switch key you can toggle through a stack of keyboards that you've configured in the Control Panel (in advance). All by itself, that would be awesome and really enhance multilingual / multi-script input. This more-or-less implements the Language key already found on Arabic and Thai OLPC keyboards, but does so for all keyboards. http://wiki.laptop.org/go/Keyboard#Special_Keys http://wiki.laptop.org/go/OLPC_Arabic_Keyboard http://wiki.laptop.org/go/File:Key_arabic.jpg http://wiki.laptop.org/go/OLPC_Thai_Keyboard http://wiki.laptop.org/go/File:Key_thai.jpg This also seems to be necessary, but not sufficient, for the utopian ideal of toggling through UI languages / glibc locales on-the-fly (without going to Control Panel and rebooting). How far away is such a promised land once we have keyboard switching? FWIW, I've added the output to the discussion page from Maliit listing the language files in a little more detail. I'll put up screenshots of the layouts once I'm a little further along with the style/layout changes (I need to do this as part of my layout change testing anyway): http://wiki.sugarlabs.org/go/User_talk:Garycmartin/Maliit Regards, --Gary cjl OLPC_kbs.ods ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Design] On Screen Keyboard – part of the 'get Sugar touch ready' feature set
On Sun, Aug 26, 2012 at 8:04 AM, Gary Martin garycmar...@googlemail.com wrote: FWIW, I've added the output to the discussion page from Maliit listing the language files in a little more detail. I'll put up screenshots of the layouts once I'm a little further along with the style/layout changes (I need to do this as part of my layout change testing anyway): http://wiki.sugarlabs.org/go/User_talk:Garycmartin/Maliit Thanks Gary. A good start. As things stabilize I'd love to work with folks to document the variants in more detail on the wiki (including links to the XML files) in a manner similar to the way the OLPC xkb designs are documented on w.l.o http://wiki.laptop.org/go/Category:Keyboard_layouts There is huge i18n/L10n potential and I can imagine a lot of interest in developing additional keyboard XML files to capture scripts that are not on Maliit's radar screen yet. cjl ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Design] On Screen Keyboard – part of the 'get Sugar touch ready' feature set
On 26 Aug 2012, at 18:02, Chris Leonard cjlhomeaddr...@gmail.com wrote: On Sun, Aug 26, 2012 at 8:04 AM, Gary Martin garycmar...@googlemail.com wrote: FWIW, I've added the output to the discussion page from Maliit listing the language files in a little more detail. I'll put up screenshots of the layouts once I'm a little further along with the style/layout changes (I need to do this as part of my layout change testing anyway): http://wiki.sugarlabs.org/go/User_talk:Garycmartin/Maliit Thanks Gary. A good start. As things stabilize I'd love to work with folks to document the variants in more detail on the wiki (including links to the XML files) in a manner similar to the way the OLPC xkb designs are documented on w.l.o http://wiki.laptop.org/go/Category:Keyboard_layouts There is huge i18n/L10n potential and I can imagine a lot of interest in developing additional keyboard XML files to capture scripts that are not on Maliit's radar screen yet. One thing to keep in mind is that the Maliit keyboard layouts _are_ the language files, so if we make even to most trivial of changes for our desired keyboard layout (move a button or add a button etc) then any new language layouts we may later add will be of minimal use to Maliit upstream, unfortunately. Would be nice if the process could go both ways, but unlikely in the short term at least. Regards, --Gary cjl ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Activity template for HTML5/Enyo
Hi Sebastien, Thanks. Very interesting indeed your WebUI. I know Flask, we use the same architecture for the Nutrino activity [1] we develop with Danone. BTW I'm not fully satisfy by this, I find it too complex (3 tiers in the same activity: Python Sugar, HTML/JavaScript, Python Flask) and of course, due to Gtk2, the support of HTML5 feature is very poor. But you're right, 0.94 and lower are the most deployed version of Sugar today. Like you, we deployed 0.94 to our Malagasy deployment only this year. Best regards from France. Lionel. [1] http://www.dailymotion.com/video/xm2zmd_olpc-france-presenting-a-sugar-activ ity-about-nutrition-at-the-2-sugarcamp-in-paris_tech -Message d'origine- De : Sebastian Silva [mailto:sebast...@fuentelibre.org] De la part de Sebastian Silva Envoyé : dimanche 26 août 2012 00:09 À : lio...@olpc-france.org Cc : sugar-devel@lists.sugarlabs.org Objet : Re: [Sugar-devel] Sugar Activity template for HTML5/Enyo Hi Lionel, Congratulations! This is a great idea. My own efforts in this area [0] have involved integrating a webapp microframework (Flask). Our team is working on a more complex ajax-webapp with this approach [1] for the Sugar Network WebUI. Alsroot and I have been discussing Enyo as a foundation for further work and it does look very useful indeed. I'm still running gtk2 version of sugar (0.94) because that is what we will have deployed in the field thruout 2013. Therefore I couldn't try it but I will take a look at the code for ideas. Regards, Sebastian [0] http://lists.sugarlabs.org/archive/sugar-desarrollo/2011-July/000107.html [1] http://wiki.sugarlabs.org/go/Platform_Team/Sugar_Network/Web_UI -- Sebastian Silva sebast...@somosazucar.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar-devel Digest, Vol 46, Issue 123
Hi Edward, Thanks. Using my template in existing activity is easy. It just need a WebView Widget which encapsulate the WebKit browser. But, of course, it require Sugar 0.96 - Gtk3. Creating interactive tutorial could be a good idea because, with this framework, the HTML5 page could be notified when a Widget has changed or could launch an action on a Widget. So, it's basic for an interactive tutorial. I don't know for Scratch but AFAK, EToys is built with a very different approach than Sugar Python so I'm afraid it could not use in the same way. Best regards from France. Lionel. -- Message: 3 Date: Sat, 25 Aug 2012 18:11:54 -0400 From: Edward Mokurai Cherlin moku...@sugarlabs.org To: Sugar Devel sugar-devel@lists.sugarlabs.org Subject: [Sugar-devel] Sugar Activity template for HTML5/Enyo Message-ID: cadmpiaaokhd-4skfbmnvm7wba1bqqonax9xrfdqfoylzzcp...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 Excellent. I have been wanting a way to use HTML5 with various Sugar activities in the Replacing Textbooks program, both to write interactive tutorials on the activities, and to write subject-matter materials incorporating Sugar. Can you see how to do this? Can we adapt existing activities in Python and other languages to work with your template? What would it take to link to Etoys and Scratch, as the next language extension? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] search toolbar in Group view
Hi Simon, On 26 Aug 2012, at 10:35, Simon Schampijer si...@schampijer.de wrote: Hi, to have the same functionality in the Views, I would like to add a search toolbar to the Group View. That is trivial in the first place and code can be shared from the Mesh and the Group View. One thing that is a bit tricky to handle is that we use already grey icons to show that a buddy is absent at the moment. This collides a bit with the alpha representation when we do search. Is there some smart way to make that more distinguishable? I know we talked once about a different search mechanism all together but maybe there is something we can do short term. Yea ;) OK so a couple of quick thoughts: 1) The current search design does _not_ grey out mis-matches, it reduces the alpha. So we do have two metaphors; buddy grey stroke for absent; full colour/faded alpha buddy icon for search. Searching for a buddy that is absent is the weakest visual case here, where you'd be left looking at a screen of faded alpha colour icons, and a grey stroke only buddy icon. I think that would still be a reasonable case. 2) The other option discussed was to reuse the grey rounded rect for the search hits, though this would clash with our mouse over/down use. Regards, --Gary Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] search toolbar in Group view
2012/8/26 Gary Martin garycmar...@googlemail.com: Hi Simon, On 26 Aug 2012, at 10:35, Simon Schampijer si...@schampijer.de wrote: Hi, to have the same functionality in the Views, I would like to add a search toolbar to the Group View. That is trivial in the first place and code can be shared from the Mesh and the Group View. One thing that is a bit tricky to handle is that we use already grey icons to show that a buddy is absent at the moment. This collides a bit with the alpha representation when we do search. Is there some smart way to make that more distinguishable? I know we talked once about a different search mechanism all together but maybe there is something we can do short term. Yea ;) OK so a couple of quick thoughts: 1) The current search design does _not_ grey out mis-matches, it reduces the alpha. So we do have two metaphors; buddy grey stroke for absent; full colour/faded alpha buddy icon for search. Searching for a buddy that is absent is the weakest visual case here, where you'd be left looking at a screen of faded alpha colour icons, and a grey stroke only buddy icon. I think that would still be a reasonable case. Agreed. The absent buddies are greyed out, this doesn't clash with the filtering metaphor. So for the filtered buddy icons the same alpha reduction as the other views can be used. Cheers, -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Activity template for HTML5/Enyo
2012/8/25 lio...@olpc-france.org: Hi all, I've enhanced the work of Manuel Quinones to create an activity template using Enyo JavaScript Framework. My objective was to provide a template to write a Sugar activity using HTML5 but without losing advantage of the Sugar integration. Plus, I didn't want using a HTTP Server integrated into the activity like in the Wikipedia activity. Finally, using some WebKit tips tricks (calling a JavaScript in the current page and console message handling), I finally conceived a simple framework that allow bi-directional communication between Python code and JavaScript code (using Enyo Framework). You could find the resulting source code from this framework here [1] for Python and here [2] for JavaScript. To test this framework, I wrote a sample activity (downloadable here [3]) with a part of the activity wrote in HTML5 and the other part wrote in Python. I've illustrated the power of this framework with few features: - Sending basic type or full python object to JavaScript, - Sending basic type or full JavaScript object to Python, - JavaScript Enyo controls (Checkbox and Slider) synchronized with matching Gtk control, - Passing of Sugar context (buddy nickname and color) to JavaScript, - Using Sugar toolbar to launch JavaScript event, - Handling a HTML5 canvas (a small Logo Turtle ;-) from Gtk button. A screen capture of the activity is visible here [4]. I think it's a good start to show what we could hope from this sort of integration and finally, to have more HTML5 developers writing or adapting activities to Sugar. Wow Lionel, impressive advance! Lot of thing could be done to enhance this basic framework. I hope to have time to write a real activity to work on some other interesting stuff: - Read/Write from Sugar Journal from JavaScript - Use POT localization for HTML5 resource - Using Sugar presence from JavaScript - have a Enyo theme similar to the one in Sugar? Keep the good work :) -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release JAMath-2
Activity Homepage: http://activities.sugarlabs.org/addon/4595 Sugar Platform: 0.82 - 0.98 Download Now: http://activities.sugarlabs.org/downloads/file/28195/jamath-2.xo Release notes: This version have sugargame and the sugar toolbar Thanks for Alan for put sugargame Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] conversations about sugar ui design
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
Re: [Sugar-devel] conversations about sugar ui design
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úcarhttp://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
