Re: [IAEP] [Systems] wiki design
On Sat, Mar 13, 2010 at 10:40 PM, Josh Williams j...@tucson-labs.com wrote: On 3/13/10 1:56 PM, Sascha Silbe wrote: On Sat, Mar 13, 2010 at 01:36:44PM -0700, Josh Williams wrote: I'm in the camp that it's better to set a maximum width because I think it's harder to read long strings of text. If you really want to do this (I still wouldn't like it), please at least base it on font size (em). Using pixel sizes will cause breakage for users of high resolution (DPI) screens and visually impaired users who have significantly increased the font size. If we do limit the width, I'll definitely use ems. Anyway, I'm not opposed to having it set at 100% width if you think most of the wiki users would prefer that. The question is not just what the majority prefers, but also what the drawbacks are for the minority. That's true, but I think the drawbacks are small for either case. Here are our two options, the problems I see, and typical responses to those problems. 1. Restrict the width to 62.5 em (roughly 1000px for people viewing at normal font size 16px) Argument: this will restrict people with large displays from using all of their window to fill the text. Response: Most contemporary sites are fixed width and set around 1000px, so those users are used to interacting with similar websites. 2. Don't restrict the width. Argument: Causes hard to read text when the browser is in full screen mode or when taking up a large portion of the screen. Response: Make the browser window smaller or zoom the page. Are there any other drawbacks that I'm missing? I don't really think this is just a decision I should make arbitrarily, so any thoughts on this would be appreciated. I agree that sites which don't restrict the body column width are generally more difficult to read, and it can be frustrating to users who have a number of tabs open in a single window to continually resize that window to make those sites readable. I'd put in a vote for setting a max-width (instead of a fixed width), specified in ems, so that the line length is comfortable for readability regardless of the font size, and the layout can still scale down gracefully for narrower viewports, such as on mobile devices. I'd recommend something around 80–100 characters per line for best readability. (It looks like about 100 now, so no change needed there.) I'm happy to see you've already set the line-height to something reasonable, too. Anyway, I love the redesign. I think it's looking great! nice work. One other note I had was that I'd like to see hover effects on links in the main articles, just like those in the menu to the left. Eben That being said, thanks for working on a new style! I too would love a wiki that looks sweeter (i.e. more like the Sugar UI). CU Sascha No problem! Thanks for the feedback! Josh ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Systems] wiki design
On Sat, Apr 3, 2010 at 1:14 PM, Bernie Innocenti ber...@codewiz.org wrote: On Sat, 2010-04-03 at 11:44 -0400, Eben Eliason wrote: I agree that sites which don't restrict the body column width are generally more difficult to read, and it can be frustrating to users who have a number of tabs open in a single window to continually resize that window to make those sites readable. I'd put in a vote for setting a max-width (instead of a fixed width), specified in ems, so that the line length is comfortable for readability regardless of the font size, and the layout can still scale down gracefully for narrower viewports, such as on mobile devices. I'd recommend something around 80–100 characters per line for best readability. (It looks like about 100 now, so no change needed there.) I'm happy to see you've already set the line-height to something reasonable, too. Anyway, I love the redesign. I think it's looking great! nice work. I totally agree. Josh, is anything that you'd like to change before we move your work to the production wiki? One other note I had was that I'd like to see hover effects on links in the main articles, just like those in the menu to the left. I'm +1 on adding a hover effect, but -1 on removing the underlining hint, which would make the links harder to distinguish. Yeah, that's fine. Maybe keep the underline in the default state, but remove it in the hover state when the background color changes. Eben -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] turtle art: 2 instances, no?
On Mon, Sep 7, 2009 at 8:15 AM, Gary C Marting...@garycmartin.com wrote: Hi Bill, On 7 Sep 2009, at 12:09, Bill Kerr wrote: I can't see any way to load 2 instances on the SoaS version If I have a project loaded, saved and named Then go into the journal and try to load an older saved version then it doesn't load but puts me back to the current open version I have to first close the current version and then open the older version to get it This is not a bug with TurtleArt. It's (in my view) the major design backfire that is the Keep button... Keep is not like a copy, duplicate or 'save as' file operation in other OS environments. Sugars Keep is actually a (bad) attempt at Keep version snap shot, unfortunately no where in the Journal UI is this visually indicated/ referenced. Think of Keep a little like non-linear undo states stored to Journal. This is true. Perhaps we could make it more explicit by naming it Save a version instead. What we really need is a Keep a copy secondary action that can be used in the manner many desire, to create a clone of the instance with a separate activity ID. Equally important, we should have a Make a copy or Duplicate button in the Journal to enable this as a top level function there. Here's some more background reading: http://lists.sugarlabs.org/archive/sugar-devel/2009-July/016494.html The problem with all this is that Sugar currently treats all versions you Keep from an activity as the same activity. You can only have one of the versions active at once, this is what you're seeing when This is actually another bug. On several of the threads discussing versions this came up, and it's clear that there is value to having multiple versions of the same activity instance open at once, specifically for the purpose of copying elements from an older version into a newer one. Revising Sugar to make this possible, regardless of when we land version support, would be beneficial. you try to resume (what you think is another old activity is actually a version) and Sugar switches to the current version of it you already have open. We also discussed that this might be a choice (to join the existing, or work on the older version). Eben To create fresh new activities, you need to: 1) start new activity 2) create masterpiece 3) stop activity 4) goto step 1 If you ever find yourself clicking Keep give your self a small jab in the hand with a sharp protractor ;-) In every release of Sugar to date, Keep == horrible design failure, even for the upcoming 0.86. The problem is the real deal (true versioning) is always just over the horizon, like the pot of gold at the end of the rainbow, and the blasted button some how makes it through (and causes way more grief then it ever solves as the common use case is I want a duplicate copy of this). Regards, --Gary Also if I am working on a project and remember an idea from a sample project then I can't just load the sample view the idea and then quickly return to my current project to implement there I have to close current project, then open sample and view idea, then close sample, then reopen current project, etc. Please correct if I am wrong about this ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] svg animations, no?
On Thu, Aug 27, 2009 at 7:46 AM, Tomeu Vizosoto...@sugarlabs.org wrote: On Thu, Aug 27, 2009 at 12:43, Bill Kerrbillk...@gmail.com wrote: Sugar does not support SVG animations? I just tried to replace the XO icon with an SVG animation as an extension of the http://en.flossmanuals.net/Sugar/8_4/ModifyingSugar exercise - the icon replaced but was not animated. I'm seeking confirmation that this is correct and would be interested in the reason too Sugar uses librsvg to render all SVGs, I'm not sure which are the capabilities of this library regarding animations. I think the main issue is that icons are heavily cached/optimized, and so the library is being used to render the icons at a particular size and in particular colors, but not to actually display it on screen. The icons on screen have been rasterized. Adding animation would require adding a new icon class (kind of like the pulsing icon class). That might be doable; I have no idea. The performance probably won't be great (at least on XOs). We had lots of trouble just rasterizing all of the static icons in complex views such as the neighborhood without noticeable performance hits. Eben Regards, Tomeu ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Adding a word-count to write
On Sat, Jul 18, 2009 at 10:44 PM, Gary C Marting...@garycmartin.com wrote: Hi Martin, On 18 Jul 2009, at 22:58, Martin Sevior wrote: We do not expose the underlying code to extract the numeric value of the word count from a document at present. It would trivial to add that to the API if there was consensus this would be a useful thing to do. Now is a good time to put in such requests because we're just finishing off the 2.8 release. However you can pop up the AbiWord modeless Word Count dialog by doing: self._abiword_canvas.invoke_cmd(dlgWordCount,,0,0) Thanks. Just added this as a toolbar button to test. For those interested, here's what it looks like in Sugar. With Sugars fullscreen interface design, the use of dialogues is rather finicky as it's easy to loose the dialogue behind to the desktop background layer: This will give you document statistics as you type. I can imagine that having the word count auto-updating in the toolbar would be a neat little feature for the Write 0.86. It might one of those high ceiling features for users to discover. One might also think of find, replace and goto all being implemented in the toolbar. FWIW, find is available under the Edit tab (but no replace functionality), and goto (page) is available on the View tab (but not goto line number). We have to careful to remember our target audience though. +1 I think it took some strong restraint to keep the number of features exposed down to what we see today in Write :-) +1 I'm not sure this is a feature that many kids will need. However, if teacher/child feedback indicates it would be a nice addition, I'd recommend displaying these statistics within a palette. There could be a statistics button that, when hovered or clicked revealed a palette containing whatever pieces of info are worth exposing. I'm not sure what tab/toolbar that button would fit best within, though... Eben If you have the time – I've been looking for feedback on a new Toolbar design that may be arriving in some form for Sugar 0.86. Some of the goals are to show the Stop activity button at all times (kids often get lost in the text tabs); resolve the difficulty of small click targets caused by the narrow height text tabs; use icons rather than relying on text tab names (lower age, and improved non-illiterate access): http://wiki.sugarlabs.org/go/Design_Team/Proposals/Toolbars#Top_level_Activity_toolbar_for_Write The mock-ups specifically keep the current Write functionality and tool groupings so it can be more easily compared with the current Write implementation. Regards, --Gary ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Alternative icon design for Get Internet Archive Books, please comment
On Wed, Jul 1, 2009 at 11:18 AM, Jim Simmonsnices...@gmail.com wrote: Eben and Tony: I like your design, but if I decide to go with something like that I think my Inkscape skills are good enough to duplicate it. I think Tony makes some really good points though, so what I think I'll do is go with my own (Gary Martin inspired) design with the speed lines for now. I was not so much concerned that kids wouldn't know what speed lines are as I was that what I had drawn would be recognizable as speed lines. And apparently they are. Sure, no problem! I'd definitely recommend trying the filled browse icon in your design, since it appears you are using lines that are much narrower than the style guidelines permit (3.5 for primary stroke, 2.25 for secondary strokes). The speed lines, likewise, should probably be bumped up a little bit to 2.25. I should have release 2 of this Activity ready in a few days. The new one will have multiline table cells for long titles or lists of authors, a progress bar to indicate download progress, and the ability to choose between DJVU and PDF as a download format. This last feature is to accommodate .82 users which have a Read Activity that does not support DJVU well. Awesome. Eben Thanks to everyone who commented or tried to come up with designs. James Simmons On Tue, Jun 30, 2009 at 7:28 PM, Eben Eliasoneben.elia...@gmail.com wrote: Here's my two cents. (see attached) I like the use of the browse icon, but I've found that rendering it as a fill, rather than a stroke, works far better at small sizes. While I like the stack of books, I'm afraid it doesn't read clearly at first glance. I decided to try stamping the internet logo on the cover of the book, almost like it's an atlas of the internet archive, both to conserve space and to simplify a bit. I'll pull together a proper Sugarized SVG if it's desired. Eben On Tue, Jun 30, 2009 at 7:21 PM, fors...@ozonline.com.au wrote: Jim I like the icon of the browser on the open book To me it says: get a book from the internet Unlike the other suggestions, it can be interpreted without any prior knowledge, because it builds on the Browse and book reader icons which have their meaning defined within Sugar by these Activities. The motion lines require the reader to know this comic strip convention but the icon can be interpreted without understanding the motion lines. For third world kids, card catalogues will not work, I doubt they have seen a lot of hard bound books or bookshelves either. Mostly I think they use cheaper staple bound books. http://www.flickr.com/photos/tonyforster1/3420467967/ photo, cheap staple bound textbooks, Peru http://www.flickr.com/photos/tonyforster1/3676084455/ photo, single room school, Peru. No card catalogues, hard bound books or bookshelves in sight. (There was however a PC which they hid under the white cloth to the left, presuming that tourists would not want modern artefacts in their photos. As a missionary school, I expect it is better funded than a government school) Tony ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Alternative icon design for Get Internet Archive Books, please comment
Looks good! Eben PS. Part of the reason for the minimum stroke weight requirements was due to the XO screen itself, which swizzles to create the correct colors. Lines that are too thin appear the wrong color, since each individual pixel is either red, green, or blue, rather than each having all 3 of these components. It wasn't solely a stylistic decision, though we also liked it on that basis. In any case, keeping the primary outline (the defining shape of the icon) the standard 3.5pt is the crucial part (and it appears you've done this), for consistency across icons. On Wed, Jul 1, 2009 at 1:16 PM, Jim Simmonsnices...@gmail.com wrote: Eben, I've taken your suggestion on the globe, but making the speedlines thicker didn't look right. End result is attached. I'll try it tonight and see how it looks. And I did manage to find the style guide for Sugar icons. I won't promise to follow them religiously, since the other two icons I made seem fine to me, but at least I know what they are. Thanks, James Simmons On Wed, Jul 1, 2009 at 11:32 AM, Eben Eliasoneben.elia...@gmail.com wrote: On Wed, Jul 1, 2009 at 11:18 AM, Jim Simmonsnices...@gmail.com wrote: Eben and Tony: I like your design, but if I decide to go with something like that I think my Inkscape skills are good enough to duplicate it. I think Tony makes some really good points though, so what I think I'll do is go with my own (Gary Martin inspired) design with the speed lines for now. I was not so much concerned that kids wouldn't know what speed lines are as I was that what I had drawn would be recognizable as speed lines. And apparently they are. Sure, no problem! I'd definitely recommend trying the filled browse icon in your design, since it appears you are using lines that are much narrower than the style guidelines permit (3.5 for primary stroke, 2.25 for secondary strokes). The speed lines, likewise, should probably be bumped up a little bit to 2.25. I should have release 2 of this Activity ready in a few days. The new one will have multiline table cells for long titles or lists of authors, a progress bar to indicate download progress, and the ability to choose between DJVU and PDF as a download format. This last feature is to accommodate .82 users which have a Read Activity that does not support DJVU well. Awesome. Eben Thanks to everyone who commented or tried to come up with designs. James Simmons On Tue, Jun 30, 2009 at 7:28 PM, Eben Eliasoneben.elia...@gmail.com wrote: Here's my two cents. (see attached) I like the use of the browse icon, but I've found that rendering it as a fill, rather than a stroke, works far better at small sizes. While I like the stack of books, I'm afraid it doesn't read clearly at first glance. I decided to try stamping the internet logo on the cover of the book, almost like it's an atlas of the internet archive, both to conserve space and to simplify a bit. I'll pull together a proper Sugarized SVG if it's desired. Eben On Tue, Jun 30, 2009 at 7:21 PM, fors...@ozonline.com.au wrote: Jim I like the icon of the browser on the open book To me it says: get a book from the internet Unlike the other suggestions, it can be interpreted without any prior knowledge, because it builds on the Browse and book reader icons which have their meaning defined within Sugar by these Activities. The motion lines require the reader to know this comic strip convention but the icon can be interpreted without understanding the motion lines. For third world kids, card catalogues will not work, I doubt they have seen a lot of hard bound books or bookshelves either. Mostly I think they use cheaper staple bound books. http://www.flickr.com/photos/tonyforster1/3420467967/ photo, cheap staple bound textbooks, Peru http://www.flickr.com/photos/tonyforster1/3676084455/ photo, single room school, Peru. No card catalogues, hard bound books or bookshelves in sight. (There was however a PC which they hid under the white cloth to the left, presuming that tourists would not want modern artefacts in their photos. As a missionary school, I expect it is better funded than a government school) Tony ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Alternative icon design for Get Internet Archive Books, please comment
Here's my two cents. (see attached) I like the use of the browse icon, but I've found that rendering it as a fill, rather than a stroke, works far better at small sizes. While I like the stack of books, I'm afraid it doesn't read clearly at first glance. I decided to try stamping the internet logo on the cover of the book, almost like it's an atlas of the internet archive, both to conserve space and to simplify a bit. I'll pull together a proper Sugarized SVG if it's desired. Eben On Tue, Jun 30, 2009 at 7:21 PM, fors...@ozonline.com.au wrote: Jim I like the icon of the browser on the open book To me it says: get a book from the internet Unlike the other suggestions, it can be interpreted without any prior knowledge, because it builds on the Browse and book reader icons which have their meaning defined within Sugar by these Activities. The motion lines require the reader to know this comic strip convention but the icon can be interpreted without understanding the motion lines. For third world kids, card catalogues will not work, I doubt they have seen a lot of hard bound books or bookshelves either. Mostly I think they use cheaper staple bound books. http://www.flickr.com/photos/tonyforster1/3420467967/ photo, cheap staple bound textbooks, Peru http://www.flickr.com/photos/tonyforster1/3676084455/ photo, single room school, Peru. No card catalogues, hard bound books or bookshelves in sight. (There was however a PC which they hid under the white cloth to the left, presuming that tourists would not want modern artefacts in their photos. As a missionary school, I expect it is better funded than a government school) Tony Attached is an icon for the Get Internet Archive Books Activity. My original design, based on a card catalog drawer, can be seen at ASLO. I kind of like the original, but will replace it with something else if there is a strong preference to do so. This icon is inspired by a suggestion by Gary C Martin. I will not attempt to explain what it means; if it isn't obvious the icon is no good and I'll stick with my card catalog design. I'm still interested in other ideas. Thanks, James Simmons _ This mail has been virus scanned by Australia On Line see http://www.australiaonline.net.au/mailscanning [ get-ia-books-2-2.svg ] ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep attachment: i_book_archive.png___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] personalisation and collaboration
On Mon, Jun 8, 2009 at 5:44 AM, Tomeu Vizosoto...@sugarlabs.org wrote: On Sun, Jun 7, 2009 at 13:00, David Van Asschedvanass...@gmail.com wrote: Something has been in the back of my head for a while now, ever since I've seen the impressive capabilities of being able to share an activity with your neighbourhood. Being able to cooperatively use applications brings a new level of playability to it all, and it reminds me of when I first saw the ability for a computer game to be 'multi-player.'This gave it an extra dimension, and with it came the idea of awards for completing certain things, which would be displayed in your dashoard somewhere.The award system seems even more relevant for education than it did for games. We'v aleady mentioned the benefits of an award sysem so I'm not going to regugitate that, but what hasnt''t really been spoken about is, how and what kind of personal details should the journal store and share. I see this as a customisable option, something that can be as simple as only sharing first names, or sharing the name of your pet, your favorite colors and foods, the languages you speak. This detailed information about a person is extremely valuable to the underlying system, as it can potentially match people against each other. This would allow for some interesting possibilities when it comes to collaboration, such as the system suggesting users to challenge/collaborate with based on personal information. I thought about having a robot that lives on an irc channel capable of helping with the collaboration procedure, as well as listing achievements, giving data on which users want to collaborate, giving help on how collaboration works with particular activities, listing which servers have open collaboration, showing the most used/highest rated collaborating activities, etc. I guess tagging of buddies is related in some measure to this? http://wiki.sugarlabs.org/go/Development_Team/Release/Roadmap/0.86#Groups Yes, I think these goals are definitely in line. Our early mockups for the XO palette included info such as a photo, name, age, and interests, or perhaps other personal info so that kids could meet and learn about each other online. Moreover, as Tomeu mentions, these tags and metadata would be searchable in the neighborhood, so that searching for chess would brinfg not only chess activities, but anyone who mentioned they liked chess in their profile. Regards, Tomeu I havent thought about this too much in depth, but I know coding a bot is not too hard. I see it as an extension to the speak AI, and encouragement to join irc. We can even get the bot to accept uploads of raw learning materials categorised by subject, which can then be used by content creators. it itself could give out quizzes based on particular subjects, or interesting pieces of information/knowledge. It could be taught new information, by feeding it localised knowledge. It would be important to know where we set the limits to what it can do. Just some food for thought... This is a very interesting idea. Another perspective to think about this from is a persistent activity. That is, it could just be some activity that's running on a server all the time, rather than just on personal XOs, so that it remains available permanently even when everyone else leaves. naturally, this approach would require some way for the server to push some code to the client, temporarily or permanently, in order to interact with the persistent activity. That idea is loosely related to the future goal of seamless transfer and installation of activities which one doesn't have when joining them in the neighborhood. Eben David (nubae) Van Assche ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Marketing] [Sugar-devel] [SoaS] Request for Artwork: Boot Screen
On Thu, Jun 4, 2009 at 7:24 AM, Sean DALY sdaly...@gmail.com wrote: http://wiki.sugarlabs.org/go/Marketing_Team/Boot_Logo Christian - I myself prefer the rays to dots which I feel too closely resemble networks in the Neighborhood view, confusion is possible (networks being connected to at startup?) Fred - I'm willing to try that sunrise metaphor, tonight if I can (travelling today) Re splash page with logo: in my next mockup I'll leave off the example school logo.and move that frame to the end. It might be better to reserve a frame for customizable logo or message, before or after the Sugar spash page Yes, in that mockup the first screen is kind of overwhelming with several logos and a few pieces of textual information. At the same time, we tried very hard to eliminate the slideshow effect that feels (well, is) like a bunch of marketing material that detracts from the UI. I think the Sugar logo should stand alone, so it reads powerfully, and then be replaced in short order by the XO. Perhaps we could entertain a text only solution to identifying the school, in gray beneath the sugar logo. Thoughts? Version info: In fact I feel strongly about showing version information... or its corollary, making it easy to find. Teachers, I think it's more important that we make it easy to find in the UI. Kids won't reboot that often, and it would be silly to reboot just to find that info. parents, admins, G1G1 donors unfamiliar with Sugar will not have the foggiest idea how to hunt down version information (Learners might not have trouble finding it - they will explore their machines ad infinitum - but they can't be expected to know about versioning). We are about to embark on hundreds of thousands of XO-1.5s running v0..84 which will coexist with a huge installed base of v0.82 (and many earlier); SoaS with its simplified numbering scheme will (we hope) sow the seeds for preinstalled Sugar in distributions for education projects. We may be deploying v0.86 at the end of the year... aside from how we manage the Activity compatibility matrix, we need to make such info *extremely* easy to track down for someone interested in checking if Sugar + Activities are up-to-date. Our strategy for teacher buy-in is star marketing on Activities (see press releases); making Activity installation/upgrade simple this summer is part of what we need to do to make SoaS possible in the classroom. Helping users understand what version they have (of Sugar, of each Activity) is a key aspect of that. I agree that it's unpleasant to see numbers at boot time (especially a datestamped snapshot number). Why don't we borrow an idea from Apple? We basically have this already. We ust happen to have an XO in the center of the screen, instead of an apple icon in the upper left. The info is actually in the About my XO section of the settings, which might be one step too far. We could go back to an earlier design for the XO menu and have a direct About my XO menu item which jumps directly to the correct settings panel. We could also separate the About my XO panel from settings, removing it from the settings panel completely and showing it as it's own modal dialog accessible via an About my XO menu item. I would be fine with either approach. They have a tiny apple icon in the upper-left corner of the screen; clicking on it opens a window with the processor, RAM and OSX version number. In addition to the About my computer section in the Control Panel, perhaps we could show the version in the Frame? The bottom bar has room I think. There's no need to expose this information directly. It will only be needed on occasion, and the Frame is designed for the information you want to carry with you all the time. When we start to get consolidated feedback, we will know if difficult-to-find version info is a problem for Sugar / Activity updaters or not. I feel sure it is and showing the version in the Frame (the one-glance status communicator) seems to me a good approach which would let us skip info in the splash screen. Nota: my idea would be for each version to change the Sugar logo color too... potentially allowing troubleshooters to ask what color is the Sugar logo? and match that to the version number. I would much rather see the logo change colors with each boot, but changing with each release is a pretty cool idea. I would support that. I think there are enough of combinations to make wrapping around a non-issue, as long as we only change the color for major releases (2 per year, on average). Finally, regarding the animation itself: I Think the gray dots are still the best option, and the clearest. They fit the style, but won't be confused with APs. If we can in any way manage it, coloring the XO in the child's chosen colors is really the way that color should be introduced. The colored dots seem to undermine the importance of that metaphor, for me. Everywhere else in the UI, color relates to
Re: [IAEP] [Marketing] [Sugar-devel] [SoaS] Request for Artwork: Boot Screen
On Thu, Jun 4, 2009 at 11:07 AM, Walter Bender walter.ben...@gmail.com wrote: On Thu, Jun 4, 2009 at 10:31 AM, Eben Eliason eben.elia...@gmail.com wrote: On Thu, Jun 4, 2009 at 7:24 AM, Sean DALY sdaly...@gmail.com wrote: http://wiki.sugarlabs.org/go/Marketing_Team/Boot_Logo Christian - I myself prefer the rays to dots which I feel too closely resemble networks in the Neighborhood view, confusion is possible (networks being connected to at startup?) Fred - I'm willing to try that sunrise metaphor, tonight if I can (travelling today) Re splash page with logo: in my next mockup I'll leave off the example school logo.and move that frame to the end. It might be better to reserve a frame for customizable logo or message, before or after the Sugar spash page Yes, in that mockup the first screen is kind of overwhelming with several logos and a few pieces of textual information. At the same time, we tried very hard to eliminate the slideshow effect that feels (well, is) like a bunch of marketing material that detracts from the UI. I think the Sugar logo should stand alone, so it reads powerfully, and then be replaced in short order by the XO. Perhaps we could entertain a text only solution to identifying the school, in gray beneath the sugar logo. Thoughts? +1 I don't have an XO nearby my to try this, so perhaps someone could investigate for me. We also need to decide how many frames we show the Sugar logo for before switching over to the XO. One frame might not be long enough. This is important because the number of dots shown (if we do dots) will be directly impacted. I'd wager that the Sugar logo should remain for perhaps somewhere from 10% to 25% of the boot duration (which may or may not be anything close to 1/10 or 1/4 of the frames). Eben Version info: In fact I feel strongly about showing version information... or its corollary, making it easy to find. Teachers, I think it's more important that we make it easy to find in the UI. Kids won't reboot that often, and it would be silly to reboot just to find that info. parents, admins, G1G1 donors unfamiliar with Sugar will not have the foggiest idea how to hunt down version information (Learners might not have trouble finding it - they will explore their machines ad infinitum - but they can't be expected to know about versioning). We are about to embark on hundreds of thousands of XO-1.5s running v0..84 which will coexist with a huge installed base of v0.82 (and many earlier); SoaS with its simplified numbering scheme will (we hope) sow the seeds for preinstalled Sugar in distributions for education projects. We may be deploying v0.86 at the end of the year... aside from how we manage the Activity compatibility matrix, we need to make such info *extremely* easy to track down for someone interested in checking if Sugar + Activities are up-to-date. Our strategy for teacher buy-in is star marketing on Activities (see press releases); making Activity installation/upgrade simple this summer is part of what we need to do to make SoaS possible in the classroom. Helping users understand what version they have (of Sugar, of each Activity) is a key aspect of that. I agree that it's unpleasant to see numbers at boot time (especially a datestamped snapshot number). Why don't we borrow an idea from Apple? We basically have this already. We ust happen to have an XO in the center of the screen, instead of an apple icon in the upper left. The info is actually in the About my XO section of the settings, which might be one step too far. We could go back to an earlier design for the XO menu and have a direct About my XO menu item which jumps directly to the correct settings panel. We could also separate the About my XO panel from settings, removing it from the settings panel completely and showing it as it's own modal dialog accessible via an About my XO menu item. I would be fine with either approach. They have a tiny apple icon in the upper-left corner of the screen; clicking on it opens a window with the processor, RAM and OSX version number. In addition to the About my computer section in the Control Panel, perhaps we could show the version in the Frame? The bottom bar has room I think. There's no need to expose this information directly. It will only be needed on occasion, and the Frame is designed for the information you want to carry with you all the time. When we start to get consolidated feedback, we will know if difficult-to-find version info is a problem for Sugar / Activity updaters or not. I feel sure it is and showing the version in the Frame (the one-glance status communicator) seems to me a good approach which would let us skip info in the splash screen. Nota: my idea would be for each version to change the Sugar logo color too... potentially allowing troubleshooters to ask what color is the Sugar logo? and match that to the version number. I would much rather see
Re: [IAEP] [Sugar-devel] [SoaS] Request for Artwork: Boot Screen
On Sat, May 30, 2009 at 12:58 PM, Sean DALY sdaly...@gmail.com wrote: Re: grey vs. colors in progress: Actually, I have an issue with all-grey... users could worry that colors are not working in the Sugar UI. Again, the goal here would be to switch to a colored XO as soon as possible. If we can do this earlier in the boot process, we should. I think we should consider colors although I do appreciate the still loading context communicated by grey. Also, my mockup which first shows the Sugar logo, as Christian suggested, would make it clear that the screen is functioning correctly before the gray XO appears. I will post a mockup later expressing that approach; grey dots present right from the start (ring power!), filling in with color during progress... the ring approaching colors from grey I don't feel that the technicolor approach with the dots is actually conveying the right message. The boot sequence is really supposed to be about the XO, and the child's one chosen set of colors. Introducing lots of colors reduces the personalization, I feel. I'd stick to at most one other set of colors, for the logo. I would not recommend customizing the splash/progress from within Sugar... boot time is often a tense moment fraught with impatience (especially after a freeze/crash) and predictability in how Sugar usually loads is I think desirable This wouldn't change the sequence; it would only change the color of the logo, which I don't think would cause confusion. Instead, this would be in keeping with Sugar's identity: just as the logo changes on each page of the website, so too the logo would change for each boot. If we can randomize the logo color, presumably we could also render the XO in proper colors and show that much earlier in the boot sequence. We could also blink from gray to colored (in leu of smooth pulsing), perhaps, though I'd have to see it. It might look awful, especially since the frames aren't all shown for the same duration. Eben thanks Sean On Sat, May 30, 2009 at 6:22 PM, Gary C Martin g...@garycmartin.com wrote: On 30 May 2009, at 16:36, Christian Marc Schmidt wrote: I agree with your points--comments below: On Sat, May 30, 2009 at 10:30 AM, Gary C Martin g...@garycmartin.com wrote: Hi Christian, On 30 May 2009, at 10:17, Christian Marc Schmidt wrote: Hi Gary, this looks good, though I wonder about the loss of the XO in the center. The boot sequence was intended to establish the UI, and in many ways the XO does signify the Sugar brand as much (more?) as the logo. Suggestion: Could we not simply show the logo for a few seconds, before transitioning into the current boot sequence? I'd hate to lose the current sequence, I think it works very well, and Eben will attest that much time was spent arriving at where we are today... Yes, agreed, the original boot up is very hard to beat (showing a child as central). Just bouncing ideas about here. My only criticisms of the original would be: 1) not liking the kid icon breaking into a rotating arrow treatment (seems too forced/smart, the whole XO icon is a stronger identity, appearing dots show progress just fine) Yes, I fully agree! A stationary XO icon would be simpler, less forced. 2) seemed odd for the dots to appear from 6 o'clock to 6 o'clock (12 to 12 feels more natural to me) Agree with that, too. Cool. There's a sample animation of the 2 above uploaded. 3) lack of any colour (though this is tough to avoid breaking HIG iconography on colour use) Here, I think it would be best if the XO would have the colors set in the UI... Sebastian is truly, madly, deeply going to hate you for this suggestion ;-) I do like that use of greys to signify that 'things are not ready yet' so I'm on the fence here. I did try another animation with the dots appearing in the 12 logo fill/outline colours. I did wonder about showing them all as grey from the start, and then lighting up with colour. Regards, --Gary Regards, --Gary Christian On Fri, May 29, 2009 at 10:59 PM, Gary C Martin g...@garycmartin.com wrote: Hi Folks, Just to get a basic, safe, default starting point in there, I've uploaded one simple treatment to: http://wiki.sugarlabs.org/go/Marketing_Team/Boot_Logo#Sugar_Boot_Logo_Animations Will try to upload a couple more tomorrow. Night, --Gary P.S. Should pull this back on list, your call Sean, but probably worth getting a couple more ideas up so that folks can input to some alternative treatments. On 30 May 2009, at 00:58, Sean DALY wrote: Christian, Eben I'm not sure if you are on sugar-devel but this is I think an outstanding opportunity for Sugar branding, celebrating Sugar interface.iconography and greeting children. I know nothing about the plymouth boot animator, but i deduce that consecutively named files will do the trick I'm willing to attack this but before I try scraping screenshots, do you guys have any interface assets
Re: [IAEP] [Sugar-devel] journal criticism
On Thu, May 28, 2009 at 5:34 AM, Albert Cahalan acaha...@gmail.com wrote: James Zaki writes: Understanding hierarchical file structures use the concepts of containers and recursion with no limits (except for total capacity). It is not naturally intuitive, like a tree where branches get smaller from the trunk with fruit/leaves only at the end nodes. Empirically I've seen many new people approach computers (non-tech elder-relatives included), and hierarchical structures are not initially utilised. It was a secondary focus that had to be learnt out of necessity. Perhaps the concept is easier to learn as a child. If you've gone many decades without it (non-tech elder relatives) and gotten set in your ways, you may be at a disadvantage. Let's not leave the next generation at a disadvantage too. Perhaps an activity/game could be made that teaches the concepts of a hierarchical file structure. That won't get enough use. Learning to deal with the general features of modern computing is much of the reason why the XO even exists, yet I'm pretty sure most of us agree, and that you already know, that this is precisely not the case. Sugar was not designed so kids could learn to use computers. It was designed so kids could learn. Learning about computers is certainly a subset of that goal, but by no means the primary one as you suggest. /me notes the name of the list... the children are denied the opportunity to learn about directories. An activity which presents these topics would provide such an opportunity for those kids inclined to explore it, would it not? It seems that you are confusing opportunity with obligation. Incidentally, I would actually like to see some changes come about to the underlying data structures of the Journal so that it isn't so completely alienated from the filesystem itself. I think many others would too, but I don't think that forcing that on kids is particularly useful. Still, making underlying changes to provide the opportunity for kids to dig in deeper — via an activity, or via the command line — is a worthy goal. Eben ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Marketing] idea for consolidated Sugar feedback + a new name for our users
2009/5/26 Sean DALY sdaly...@gmail.com: Sugar, to me, represents the courage of starting from scratch to build the best learning environment for kids there is. With the associated risks - of being different, being in unfamiliar territory, doing things in untraditional ways. I can't bring myself to call my kids users of Sugar. Yet, a name for their role when they are doing/making Sugar is appropriate... they have a place, they have a colored symbol of themselves... a shared experience with others who are there to do something very similar. We find it normal to class people by what they do: Chess players practice openings. Knitters often prefer purl stitching. Bicyclists often wear bright colors to be more visible. In each of these cases, the role of the person is in some way defined by the necessary objects - Chess players with a chessboard and pieces (and usually another chess player), knitters with needles and yarn, bicyclists with their bikes. It's obvious that these labels are reductive, but what is gained is that they are precise - they are descriptive in a way users can't be, it's too generic. The idea behind users is to be all-inclusive, since computers are general-purpose data processing machines. I would submit that Sugar is a special case because its users are children... and I appreciate Jonas when he says that we grownups don't need our roles to fit into traditional descriptors either. That's outside-the-box thinking in my view. To Eben - on the contrary, I think it's important to publicly complement our Activities (capital A since collaborative applications specific to Sugar) with Learners (capital L since users with a role specific to Sugar). I don't think this nomenclature will confuse anyone, but instead clarify Sugar's positioning and differentiation. Teachers will understand it right away I think. Yeah, I buy that. Another reasonable term (in keeping with Activities) would be Actor, but unfortunately that's already a term overloaded in a number of ways, both in the specific sense of the thespian, or in a wholly generic sense of an actor in a system (which has pretty negative connotations with regards to our Learners!). I think it will be clear enough that the term Learner relates most directly to children, but by proxy to all other individuals engaging the Sugar UI, such as teachers, developers, etc., so I like it. It might take some getting used to, though, and it still might be friendlier in some cases to say When a child does x, the interface does y instead of When a Learner does x, the interface does y. But I can see Learner having god applications, and particularly in the aggregate: The Sugar community wants Learners to grow through their interaction with Sugar... Eben Sean On Tue, May 26, 2009 at 9:04 PM, Jonas Smedegaard d...@jones.dk wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On Tue, May 26, 2009 at 02:02:40PM -0400, Samuel Klein wrote: Docs that don't use familiar language can be a turnoff. 'User' is a familiar nuisance. 'Supporter' might also be apporpriate, since some people who follow and care about sugar do not use it day to day and are passing on the opinions of others, or their observation of others. I really like the term Learners. It indicates awareness - active participation. The term Users to me is more related to Consumers (not the word itself, but its use in my part of the world). I agree that there are others involved in Sugar than Developers and Learners. But as I see it, the examples raised - Supporters - are not Users either :-P I do not consider myself a Sugar Developer, and not a Sugar Learner. I consider myself a Sugar Packager and (as representative of Debian) a Sugar Distributor. Oh, and while we are at it: I suggest calling it Authors instead of Developers. Developers tend to emphasize the techies which is quite unfair especially to a project like Sugar: Authors include both code Programmers, graphics/interface Designers and content Writers/Composers/Illustrators. Authors → Packagers → Distributors → Deployers → Administrators → Learners (arrgh - too long to fit a single line :-( ) ...and alongside all of those are Supporters, which includes Fundraisers, Managers and Inspirators. Regards, - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREDAAYFAkocPTUACgkQn7DbMsAkQLi7KQCbBmbcmluM+mhpsuvgJ08Y1sZj qeYAn0XIRmdYBgphUFuwQC9aKBg1RnlI =+yH1 -END PGP SIGNATURE- ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!)
Re: [IAEP] design meeting
I'm going to be out of town on Sunday. Is tomorrow a possibility? I'd hate to push it off yet another week. An earlier time on Sunday could also work...8:30am Eastern, perhaps? Eben On Fri, Apr 17, 2009 at 5:08 PM, Christian Marc Schmidt christianm...@gmail.com wrote: Hi everyone I would like to propose that we hold a UI design meeting this Sunday at 11am EST/3pm UTC, to discuss a test protocol to measure the effectiveness of the current Home view, and quantify specific design tasks that we could work on for the next release. Please let me know if you would like to join but can't make it then. Thanks, Christian -- anyth...@christianmarcschmidt.com http://www.christianmarcschmidt.com 917/ 575 0013 ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] design meeting
I'd like to attend, but I won't be available until at least 7pm tomorrow. I'm available on this or the following weekend. Eben On Thu, Apr 9, 2009 at 10:59 AM, Christian Marc Schmidt christianm...@gmail.com wrote: Hi Tomeu--I think it's important that you are there, since I wanted to talk about our upcoming observations. Should we reschedule for the following weekend, or is tomorrow afternoon a possibility? Christian On Thu, Apr 9, 2009 at 10:36 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Thu, Apr 9, 2009 at 16:03, Christian Marc Schmidt christianm...@gmail.com wrote: Hi there I'd like to propose a design meeting this Sunday to discuss a test protocol that we can use to help evaluate the Home view. Please join us at 11am EST (3pm UTC) on Sunday at #sugar-meeting. I won't be able to attend, but will follow up afterwards. Regards, Tomeu Cheers, Christian -- anyth...@christianmarcschmidt.com http://www.christianmarcschmidt.com 917/ 575 0013 ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- anyth...@christianmarcschmidt.com http://www.christianmarcschmidt.com 917/ 575 0013 ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Unified Objects (was Unified bundles)
On Wed, Apr 8, 2009 at 2:20 AM, Aleksey Lim alsr...@member.fsf.org wrote: If I understand Wade correctly the one of the main purposes(at least) is not hiding content bundles somewhere(for example in Browse's bookmarks) ..and I see your concern(for what reason we should create new entities if there are lots of existed content - Gutenberg's texts, pdfs, etc) ..I was thinking a bit this morning :) and here it is proposal from my side: Expand Unified Bundles to Unified Objects Preamble. Separation all objects on verbs and nouns can be failed in some cases - and moreover it will be failed when sugar will be used for purposes that sugar was designed for - Create, Reuse, Share. This CRS scheme works(more or less at present) for content since we have Journal to store objects, but what about Activities? We should encourage people CRS theirs activities as well. Only one but - current sugar cannot work with many versions installed. At the same time this multi versioning is cornerstone of CRS activities since we have (should have) many versions of one particular activity installed on the same box. And these versions could include home made activities not only official ones. User should have possibility to treat all these versions(of one activity) effectively to CRS them. Home View should mutate from storage of activities to Tags View of Journal objects. It could have tags cloud and etc. Another Wade's idea[1] could useful here. Proposal. To achieve this target, instead of inventing new versioning scheme in sugar (in addition to Journal), I propose treat Activities as regular Journal objects. I'm a little confused by this comment, as this is already the case. Activities have entries in the Journal just as anything else does, and are, in fact, objects in that sense. They're special objects since they spawn fresh new objects by default, but the activity bundle is still an object in itself, and should be resumable with other activities which understand that object type (develop is one example; a future bundle (zip) activity would be another). Well, it couldn't solve multi versions issue for activities out of the box, but I'm strongly for having *only one* storage for content versions and activities versions(since we could treat current activity as a source(noun) to produce new activity). Right. The Journal doesn't have versions yet, but was designed to. There's no fix for that but to add the functionality, but as mentioned above, this functionality will automatically apply to activities as well as other objects already. Benefits. With this scheme accepted user will have unified interface to all objects(and theirs versions) - content(generated by activities or downloaded from the internet) and activities(downloaded, transfered from friends and home made). The Home view is not the only place activities live; it's just an easily accessible view which makes it easier to see all installed activities at a glance, instead of filtering or digging through the Journal to find them. We could treat ASLO(Activity Library) as a Objects Library and encourage people share theirs objects(not only activities) via activities.sugarlabs.org(objects.sugarlabs.org? or library.sugarlabs.org?) Returning to Unified Bundles vs. Gutenberg existed texts, we have no conflicts at all - we could gain all these objects from Tags View (former Home View) and open them by one click. I urge caution here. We've considered methods of bringing all kinds of objects (not just activities) into Home in the past, but it's a problem to be dealt with carefully. For one thing, we desired not to introduce lots of extra management facilities for defining what lived in Home. I'd need some detailed proposals of how this might work to be convinced it's a good idea. Also, we don't want to duplicate the Journal, or take away its intended use by overloading Home too strongly. Eben Any comments are welcome in ml or on [2] [1] http://wiki.laptop.org/go/User:Wade/Ideas/Activity_Management#Annotated_Concept_Sketches [2] http://wiki.sugarlabs.org/go/Unified_Objects -- Aleksey On Tue, Apr 07, 2009 at 03:40:21PM -0500, James Simmons wrote: Wade, Since two of my Activities are referred to by name in your proposal I suppose I should have an opinion on it, but I don't fully understand the proposal. It sounds like you want to mix content and Activity in the same bundle. So I guess you could write some sort of presentation using HTML and JavaScript and bundle it up like an Activity that contains a pointer to the Browse component needed to use it? You mention that Activities like Read, Read Etexts, etc. don't create content, and thus are not like real Activities. That is currently true, but lately I've been thinking of adding an Annotation feature to Read Etexts which would let the user attach notes to individual pages of the etext, as well as highlight passages with a yellow background (like marking
Re: [IAEP] Unified Objects (was Unified bundles)
On Wed, Apr 8, 2009 at 1:54 PM, Wade Brainerd wad...@gmail.com wrote: On Wed, Apr 8, 2009 at 9:12 AM, Eben Eliason eben.elia...@gmail.com wrote: On Wed, Apr 8, 2009 at 2:20 AM, Aleksey Lim alsr...@member.fsf.org wrote: Proposal. To achieve this target, instead of inventing new versioning scheme in sugar (in addition to Journal), I propose treat Activities as regular Journal objects. I'm a little confused by this comment, as this is already the case. Activities have entries in the Journal just as anything else does, and are, in fact, objects in that sense. They're special objects since they spawn fresh new objects by default, but the activity bundle is still an object in itself, and should be resumable with other activities which understand that object type (develop is one example; a future bundle (zip) activity would be another). I think the Journal is capable of holding activity *bundles* as objects. But the actual activity that you launch lives in /home/user/Activities or in /usr/share/sugar/activities and has no connection back to its downloaded Journal object. This is an unfortunate side effect of the bundle format, which I see as a technical detail and not something that should matter to the user in any way. It sounds like Aleksey is proposing unpacking the activity bundles into the Journal, which is a really interesting idea! It would This actually sounds rather confusing, to me. Both the activity bundle (zipped) and the activity (unzipped) represent the same thing: a template for the creation of activity instances. It's just a technical detail that we need to create the unzipped version to actually run it. I think there needs to be one representation of each (version) of an activity. certainly provide a future path for activity versioning, promote the creation and modification of activities to be at the same level as creating and modifying activity instances, allow users a way to transfer their created activities around, etc. All of this, again, I see the current Journal handling just fine. If you modify an activity bundle, you (once we support it) create a new version of it. When you attempt to instantiate it, the bundle is silently unpacked in the background. The zipped bundle is what you see in the Journal, is what you click to start the activity, is what you'd want to send to a friend, or post for download, etc. All of these things are already facilitated by the Journal. The big missing piece, I find, is the lack of a Bundle activity which allows kids to peek inside and rearrange zip and other bundle formats. The Develop activity already supports opening activity bundles from the Journal. Eben My only concern is that it might blur activities and activity instances for users, which could inhibit the conceptual development of this important computer concept. Cheers, Wade ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Unified Objects (was Unified bundles)
On Wed, Apr 8, 2009 at 3:17 PM, Wade Brainerd wad...@gmail.com wrote: The idea that activities actually exist in the Journal (and only in the Journal) is really exciting to me. To fully realize this, we should unpack their .xo bundles *into their Journal entry directory*, not /home/user/Activities. Yes, that's the intended perception. It would be even better if it were also the technical reality. Also, the default Activities should be present in the Journal, which means the Journal would not be empty at install time. There was a lot of back and forth on this idea in the past, but I'm in favor of showing all pre-installed activities in the Journal, myself. In the future, if we have the proposed action/object views of the Journal, the differentiator here would be that pre-installed activities only appear as objects, since they weren't installed via interaction with the device on the part of the user. (Of course, installing updates, modifying them, etc, would all appear in the action view.) And finally, the Home view should actually be a special view of the Journal, showing all Journal entries that are activities. As Aleksey says, this would open up all kinds of possibilities for alternate Home views which are different views of the Journal. Yeah, in a sense that's what we envisioned Home to be right now. I see your point though, if currently some activities don't appear in the Journal. Cleaning that up would be great. Eben Is this the direction we should be moving in? -Wade ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Marketing] ASLO vs. Activities Portal
On Sat, Apr 4, 2009 at 1:41 PM, Sean DALY sdaly...@gmail.com wrote: hmmm I like Activity Library too... Activities Library even better... but let's think twice before we drop Sugar from it. sugar+activities is already well-referenced, but I would like to see result Nr.1 be the aslo section page. Our strategy is star marketing on the Activities (this why we always capitalize), and linking them to Sugar mentioning the collaboration and view source benefits. The idea being that Activities are not applets to be run under OSes for grownups, but part of what comes with the platform which itself runs on different systems. Perhaps we can refer to Sugar Activities Library outside our site, and Activities Library within it? Except for the aslo page which I Yeah, that's what I was suggesting, simply to keep internal references to it concise. Eben do think should be titled Sugar Activities Library for the aforementioned SEO reason. Sean On Sat, Apr 4, 2009 at 4:09 PM, David Farning dfarn...@sugarlabs.org wrote: On Fri, Apr 3, 2009 at 9:55 PM, Gary C Martin g...@garycmartin.com wrote: On 4 Apr 2009, at 03:25, Eben Eliason wrote: On Fri, Apr 3, 2009 at 10:22 PM, Frederick Grose fgr...@gmail.com wrote: To me, Portal is the weak word in Sugar Activities Portal. Portal doesn't give the warm, learning, discovery place like the word Library. So I would propose Sugar Activities Library. A place to check out activities and discovery what is free to learn. +1! Maybe just Activity Library (non-plural, and dropping Sugar unless discussing it outside the Sugar context)? +1 Activity Library sounds good to me :-) That has a great sound to it. david Although in Wisconsin schools have started calling libraries IMLCs or Instructional Media Learning Centers:) ___ Marketing mailing list market...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/marketing ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] ASLO vs. Activities Portal
On Fri, Apr 3, 2009 at 10:22 PM, Frederick Grose fgr...@gmail.com wrote: To me, Portal is the weak word in Sugar Activities Portal. Portal doesn't give the warm, learning, discovery place like the word Library. So I would propose Sugar Activities Library. A place to check out activities and discovery what is free to learn. +1! Maybe just Activity Library (non-plural, and dropping Sugar unless discussing it outside the Sugar context)? - Eben --Fred Sean and Marketing people, Could you please share your thought on naming activities.sugarlabs.org. I wonder if it is better to use a common term such as 'Sugar Activities Portal' or create a new term such as ALSO. david +1 Sugar Activities Portal Hits on three important messages we are trying to get out Sugar-The underlying system-Sugar is the core building blocks(Foundation) which activities can be built upon -Much like Sugars are core building blocks of the Human Body(Sugar at its most basic levels are essential and good) -Sugar is a set of building blocks for Education and your Mind.(Sugar as an Educational Platform is essential and good) Activities-Are the next set of building blocks that allow Teachers and Students to Learn How To Learn through active engagement. -Great activities that allow Teachers to enhance their lessons and allow for a creative hands on learning experiences for their students. Portal-Indicates a communal place to visit to access these Building Blocks. It will be important to have links that lead to information on how Teachers and Students can find and work with Developers. John Tierney ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] 2 design proposals: home view, discoverable shortcuts
On Sun, Mar 22, 2009 at 6:06 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jameson Quinn wrote: Proposal 1: home view: Filtered ring w/ side panels http://wiki.sugarlabs.org/go/User:Homunq/activity_ring_filters_and_sidepanes I'm glad that you're thinking about tagging. For all of our talk about tags, we have yet to implement anything like a usable tagging system, and without it we have essentially no organizational tools at all. It should be a high priority. However,... I don't like this design, though it does force me to think. Opinions about design are always mostly intuitive, so it's hard to justify any particular opinion. However, let me try a few suggestions: 1. Is this really necessary? The tagging system's purpose is for categorizing all Journal entries, as a student easily generates thousands of entries. However, the total number of Activities in existence is relatively small (there are what, maybe about 50 that actually run in a given build?). Are we anywhere near the point where students have so many Activities installed that the favorite/star system is insufficient? Does such a point even exist? Good question. I tend to think the design proposed is overcomplicating tagging quite a bit, but I also think that activity tags should be an important part of the system. I've long advocated a system for providing a list of default tags in activity.info, which could be used for default filter sets. Additionally, it's good that your design matches the intent for the search field, in that any number of tags could be provided as a filter on the set of activities shown in Home. I think that's a solid goal, though I don't think you should have to add a tag: syntax for this purpose. Every search should search tags by default. The key: searches should be used to search within specific metadata keys instead. We tried a number of designs in the past using these trays of various kinds, an none seemed very successful, in part because they compete with the frame. It also seems to confuse a screen which should be as simple as possible: click to launch an activity, and perhaps search to filter if necessary. 2. I find these filters confusing, and I think users would do. Star makes sense; it filters the Activity bundles themselves. Recent and Mine seem to be filters not on the bundles, but on other Journal entries. I think placing them on the Home View, where the only items shown are Activities, is tremendously confusing. Those filters should live in the Journal. Agreed. I'm not even sure we need a notion of favorites, myself. I think, instead, that organic tagging would produce natural groupings of activities (eg games, science, programming, etc), and we should strive for that. This also lets developers such as MaMaMedia or GCompris group their activities under these tags. It also lets educators create clusters of activities for specific classes or projects, etc. The purpose of the Home view is to allow users to launch new, empty Activity instances in a convenient way. Are you proposing a change in the purpose of the Home view, and if so, why is your proposal better than simply replacing the home view with the Journal? I agree. I think that the primary interface for tagging should be built into the Journal, which definitely needs a rich interface for this anyway. 3. Selecting filters by dragging them is unnecessary. A click should suffice. 4. There is no provision for filtering by multiple tags, without which tagging is a very weak organizational system. Agreed. I think the search field should provide this functionality, though. It should be possible to narrow the result list simply by adding tags to the field. Additionally, what's really needed is tag-completion within the search field, as well as a robust tag popup while searching, which suggests related tags (common tags for items which match the current filter). This should be used in the Home view (all views, really), the Journal, and for naming/tagging activities for the first time. That consistency and ubiquity would be a big win. To sum up: I think that a properly implemented search field, default activity tags in activity.info, and a tag auto-completion palette (which would be used throughout the UI) is necessary, and perhaps sufficient, to make Home and activity grouping functional. - Eben 5. The distinction between Start tagless and Start with current tag seems unnecessary and confusing. Assigning or removing a tag should be a trivial operation. 6. The Leftovers panel does not seem to add any value. Instead, we can simply grow or shrink the number of items shown on the home view itself, changing the ring into a sunflower, or eventually even a grid with scrollbars. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknGtmoACgkQUJT6e6HFtqQo3QCgg2FLeVBpRPD5eZniEOUoKGjV
Re: [IAEP] Wiki Sugar_Labs GettingInvolved links seem broken
Sure, but in this instance we're talking about anchor links which are meant to jump to specific sections of the GettingInvolved page on the wiki. These should definitely be fixed, and really needn't be absolute since they're just named anchors of the current page. - Eben On Sun, Mar 15, 2009 at 5:57 PM, Sean DALY sdaly...@gmail.com wrote: Ivan has been helping us integrate the navigation between the static intro and the wiki, as the media launch begins tomorrow morning and it is vital first-time visitors can find their way out of the wiki. On Sun, Mar 15, 2009 at 10:55 PM, Eben Eliason eben.elia...@gmail.com wrote: They're not working for me either. The links need to be updated to point to the wiki subdomain, eg. http://wiki.sugarlabs.org/go/Sugar_Labs/GettingInvolved#Translator; right now they just point to sugarlabs.org (Not sure why the links need to be absolute anyway...) - Eben On Sun, Mar 15, 2009 at 5:50 PM, Simon Schampijer si...@schampijer.de wrote: Gary C Martin wrote: Just a quick heads up, I'm afraid don't have time to look at this right now. The icon links on: http://wiki.sugarlabs.org/go/Sugar_Labs/GettingInvolved ... all seem broken, clicking on an icon does not take you to the anchor. It was working fine, not sure when it broke. The wiki did get some work done on it today, so not sure if it's related to that recent change, or just broken by subsequent wiki edits. FWIW, the image links were created with a fairly hairy template trick, but that was about cleanest possible solution given the version of media wiki and plug-ins we had back then. Regards, --Gary It works for me here. Hmmm. Regards, Simon ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Wiki Sugar_Labs GettingInvolved links seem broken
Presto. - Eben On Sun, Mar 15, 2009 at 7:42 PM, David Farning dfarn...@sugarlabs.org wrote: Can someone test to make sure the fix worked. It works for me. david On Sun, Mar 15, 2009 at 6:08 PM, David Farning dfarn...@sugarlabs.org wrote: Easy fix for now. As you suspected the problem is caused by using the full url in the link. I can just stick a 'wiki.' in front of the url. Later we can go back on make the links relative. david On Sun, Mar 15, 2009 at 5:01 PM, Eben Eliason eben.elia...@gmail.com wrote: Sure, but in this instance we're talking about anchor links which are meant to jump to specific sections of the GettingInvolved page on the wiki. These should definitely be fixed, and really needn't be absolute since they're just named anchors of the current page. - Eben On Sun, Mar 15, 2009 at 5:57 PM, Sean DALY sdaly...@gmail.com wrote: Ivan has been helping us integrate the navigation between the static intro and the wiki, as the media launch begins tomorrow morning and it is vital first-time visitors can find their way out of the wiki. On Sun, Mar 15, 2009 at 10:55 PM, Eben Eliason eben.elia...@gmail.com wrote: They're not working for me either. The links need to be updated to point to the wiki subdomain, eg. http://wiki.sugarlabs.org/go/Sugar_Labs/GettingInvolved#Translator; right now they just point to sugarlabs.org (Not sure why the links need to be absolute anyway...) - Eben On Sun, Mar 15, 2009 at 5:50 PM, Simon Schampijer si...@schampijer.de wrote: Gary C Martin wrote: Just a quick heads up, I'm afraid don't have time to look at this right now. The icon links on: http://wiki.sugarlabs.org/go/Sugar_Labs/GettingInvolved ... all seem broken, clicking on an icon does not take you to the anchor. It was working fine, not sure when it broke. The wiki did get some work done on it today, so not sure if it's related to that recent change, or just broken by subsequent wiki edits. FWIW, the image links were created with a fairly hairy template trick, but that was about cleanest possible solution given the version of media wiki and plug-ins we had back then. Regards, --Gary It works for me here. Hmmm. Regards, Simon ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] New sugarlabs website
On Sat, Mar 14, 2009 at 1:15 AM, Bernie Innocenti ber...@codewiz.org wrote: David Farning wrote: When things settle down, I would like to get google analytic running for the static portion of the site to see how the click through and bounce rate compare with the wiki. Please use our analytics account based on Google Apps for all sugarlabs.org websites: UA-6267583-1 . I guess Christian should do it, or it will be overwritten the next time he updates the website. In the future we should consider using better collaborations tools, such an SCM, to let multiple people work on the static web site. I think as a rule we should make sure that any given page with a number of related sub-pages has an index of sorts which exposes the next-level-down to make browsing as natural as searching. In other words, every sub-page should have (at least) an incoming link from its parent page, so the tree of all pages is connected in a browsable way. (We get a link from the sub-page back to the parent page—all ancestors, actually—for free.) Does anyone know how to do this in mediawiki? Dunno. I think the #1 issue with the wiki is not navigability, but clutter. We're not helping the user by increasing it with adding 10 more links to the 100+ we already have in every page. My point here is really one of discoverability, so in a sense we're arguing similar high level points. It's not easy to find what you want among 100+ links on a given page, but it's impossible to find what you want if there is no link to it at all, and search doesn't work reliably. Perhaps my previous statement about making a general rule is too strong, but I still think there are lots of places that need to be more browsable. Honestly, I think almost any situation which merits hierarchy on the wiki for logical grouping *probably* merits links from parent to child pages anyway. Consider the DesignTeam/Designs page: It discusses design goals at a high level, and it summarizes each of the posted designs, with links directly to the individual design sub pages so that people can get more detail about each. Why would we not want the DevelopmentTeam/Release page to have links to release notes for recent releases (at the very least, the most recent!)? In other words, what good is a hierarchy if it's not a browsable one? Things may as well be flat if there's no way to move through the tree. I raise the issue because I myself have fought this many times, frequently attempting to browse through the hierarchy to find things, only to find no links to pages I know full well exist. In order for a wiki to be usable, it must be both well organized and well linked (well linked doesn't imply excessively linked; just intelligently). - Eben I especially dislike the blue translation bar containing lots of weird scripts. People know to use Google Translate without every web site in the world hinting them at it. Search is currently pretty nonfunctional because mediawiki can not search within words. So we need to get rid of the CamelCase as soon as possiable:( I will ask SJ what he did on wiki.laptop.org to improve upon it. -- // Bernie Innocenti - http://www.codewiz.org/ \X/ Sugar Labs - http://www.sugarlabs.org/ ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Design for a.sl.o and sugarlabs
On Wed, Mar 4, 2009 at 5:27 AM, Tomeu Vizoso to...@sugarlabs.org wrote: Hi Josh, I'm wondering how we can move forward on this. I see two possibilities: - keep insisting to the Design team to give feedback on your mockups and reach an agreement with them after a number if iterations. Christian and I both gave some feedback on what must have been another thread. I think we should go through a few iterations if we could, to bring the wireframe of sorts into a fleshed out design consistent with the Sugar Labs web presence. A few suggestions were: use an official Sugar Labs logo and colors; use a solid white background; scratch the gradients (which aren't part of our visual language); likewise no bevels; and perhaps a design for the content areas that doesn't feel quite as enclosed. We should also discuss a bit the ways we want the site to work. I know that Josh has been designing to an XO-sized display, but there are of course ways to make the page scalable as well, which we might consider. Also, we should talk about the way we want to expose the activities. One approach is shown in the mockup—a single featured activity—but I would actually lean toward something that looks a lot like the activities page on the static portion of the site, with an array of activities with icons and brief one-line descriptions in a grid, so that it's easy to jump into any of a number of recently added activities right from the home page. I actually think the static activities page might be a good one to build out from in terms of a design, adding components such as search fields, category menus, etc. I'd be happy to find some time to iterate on the proposed design add my thoughts into this design space over the next week or so. Perhaps Christian will have insight as well. - Eben - implement your design in activities-devel.sugarlabs.org and ask the community for opinions before applying those changes to production. AFAIK, you will only need to modify two files in order to customize the look of the site: http://git.sugarlabs.org/projects/slo-addons/repos/mainline/blobs/devel/site/app/webroot/css/sugar.css http://git.sugarlabs.org/projects/slo-addons/repos/mainline/blobs/devel/site/app/webroot/img/sprite.png Regards, Tomeu On Thu, Feb 19, 2009 at 17:10, ,Josh williams joshcwilli...@gmail.com wrote: Hi, I'm working on the design of sugar labs add-ons with Mick Weiss. I've created a mock up at http://sugarlabs.org/go/AddonsPortal/Design but I've haven't been able to contact anyone on the design team as of yet. I would also like to volunteer some of my time for other projects. I'm primarily a front-end designer with XHTML/CSS JavaScript skills, but I also know some PHP/MySQL and have a background in Linux. I also enjoy creating icons, so if there are any activities developers that need icons please contact me. My portfolio is over at http://tucsonlabs.com . If you're a member of the design team or have some use for my skills, please let me know. Thanks Josh ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Design for a.sl.o and sugarlabs
On Wed, Mar 4, 2009 at 2:01 PM, ,Josh williams joshcwilli...@gmail.com wrote: Eben Eliason wrote: On Wed, Mar 4, 2009 at 5:27 AM, Tomeu Vizoso to...@sugarlabs.org wrote: Hi Josh, I'm wondering how we can move forward on this. I see two possibilities: - keep insisting to the Design team to give feedback on your mockups and reach an agreement with them after a number if iterations. Christian and I both gave some feedback on what must have been another thread. I think we should go through a few iterations if we could, to bring the wireframe of sorts into a fleshed out design consistent with the Sugar Labs web presence. A few suggestions were: use an official Sugar Labs logo and colors; use a solid white background; scratch the gradients (which aren't part of our visual language); likewise no bevels; and perhaps a design for the content areas that doesn't feel quite as enclosed. We should also discuss a bit the ways we want the site to work. I know that Josh has been designing to an XO-sized display, but there are of course ways to make the page scalable as well, which we might consider. Yeah, we could make the site a percentage based-width, with a max/min-width like the mozilla guys do it, or set the width with ems to have a truly scalable site (which I think is a very good option). The XO actually has a fairly decent resolution, so I don't think it would hurt anyone else's browsing experience to just have a fixed width. Regards, Josh Yes, you're right. I was partially biased by the scale of your mockup, which I now realize was smaller than actual size. I think another contributing factor, though, was the lack of space for content relative to the size of the page, given the wide margins, thick headers, rounded corners, and borders around all of the boxes, which was particularly noticeable in those at the bottom. (Not to say all of these are bad in themselves, but that together they add a lot of spatial overhead.) I think giving them a little more breathing room (my mockups, without boxes, are just one possible example) will give us a lighter look and can even allow us to use larger text while still fitting lots of valuable content on the page. - Eben Also, we should talk about the way we want to expose the activities. One approach is shown in the mockup—a single featured activity—but I would actually lean toward something that looks a lot like the activities page on the static portion of the site, with an array of activities with icons and brief one-line descriptions in a grid, so that it's easy to jump into any of a number of recently added activities right from the home page.I actually think the static activities page might be a good one to build out from in terms of a design, adding components such as search fields, category menus, etc. I'd be happy to find some time to iterate on the proposed design add my thoughts into this design space over the next week or so. Perhaps Christian will have insight as well. - Eben - implement your design in activities-devel.sugarlabs.org and ask the community for opinions before applying those changes to production. AFAIK, you will only need to modify two files in order to customize the look of the site: http://git.sugarlabs.org/projects/slo-addons/repos/mainline/blobs/devel/site/app/webroot/css/sugar.css http://git.sugarlabs.org/projects/slo-addons/repos/mainline/blobs/devel/site/app/webroot/img/sprite.png Regards, Tomeu On Thu, Feb 19, 2009 at 17:10, ,Josh williams joshcwilli...@gmail.com wrote: Hi, I'm working on the design of sugar labs add-ons with Mick Weiss. I've created a mock up at http://sugarlabs.org/go/AddonsPortal/Design but I've haven't been able to contact anyone on the design team as of yet. I would also like to volunteer some of my time for other projects. I'm primarily a front-end designer with XHTML/CSS JavaScript skills, but I also know some PHP/MySQL and have a background in Linux. I also enjoy creating icons, so if there are any activities developers that need icons please contact me. My portfolio is over at http://tucsonlabs.com . If you're a member of the design team or have some use for my skills, please let me know. Thanks Josh ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Design for a.sl.o and sugarlabs
On Wed, Mar 4, 2009 at 2:00 PM, Christian Marc Schmidt christianm...@gmail.com wrote: Hi Eben, these look great--very promising, and a nice way to envision extending the visual language of the static web site to other Sugar Labs microsites. I'll take a closer look at the layout and typographic treatments tonight, more soon... Thanks. Yes, that's an important goal to work for, and something I kept in mind while working on this sketch. In particular, I think that the use of a single color scheme (matching one of the logo variants) for each mini-site within the Sugar Labs web presence will give us a consistent look while individualizing the various parts (git.slo, dev.slo, activities.slo, etc.). This seems to refer back nicely to the main site which employs the whole spectrum of colors, quite literally, and serves as a portal into these other areas. - Eben Christian On Wed, Mar 4, 2009 at 11:05 AM, Eben Eliason eben.elia...@gmail.com wrote: Here are some sketches I have been playing with, for thought and critique. Nothing's finished, but I was taking some cues from the static site and the comments I mentioned in my earlier post. (I'm sure Christian will still tear it apart. :-P ) To your point Tomeu, I realize some of the layout might not be correct given the starting point, but I was working from scratch here based on what I thought would be an optimal experience (I have no proof of such optimality; opinions welcome). We may have to reorganize as necessary; we'd have to see how flexible the templates and CSS are. - Eben On Wed, Mar 4, 2009 at 10:14 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Wed, Mar 4, 2009 at 16:03, Eben Eliason eben.elia...@gmail.com wrote: On Wed, Mar 4, 2009 at 5:27 AM, Tomeu Vizoso to...@sugarlabs.org wrote: Hi Josh, I'm wondering how we can move forward on this. I see two possibilities: - keep insisting to the Design team to give feedback on your mockups and reach an agreement with them after a number if iterations. Christian and I both gave some feedback on what must have been another thread. Sorry, I must missed it. I think we should go through a few iterations if we could, to bring the wireframe of sorts into a fleshed out design consistent with the Sugar Labs web presence. A few suggestions were: use an official Sugar Labs logo and colors; use a solid white background; scratch the gradients (which aren't part of our visual language); likewise no bevels; and perhaps a design for the content areas that doesn't feel quite as enclosed. All those sounds as good suggestions to me. We should also discuss a bit the ways we want the site to work. I know that Josh has been designing to an XO-sized display, but there are of course ways to make the page scalable as well, which we might consider. Also, we should talk about the way we want to expose the activities. One approach is shown in the mockup—a single featured activity—but I would actually lean toward something that looks a lot like the activities page on the static portion of the site, with an array of activities with icons and brief one-line descriptions in a grid, so that it's easy to jump into any of a number of recently added activities right from the home page. I actually think the static activities page might be a good one to build out from in terms of a design, adding components such as search fields, category menus, etc. I'd be happy to find some time to iterate on the proposed design add my thoughts into this design space over the next week or so. Perhaps Christian will have insight as well. Well, what if first we settle on a design that doesn't change much the structure of the page from the mozilla one and then we talk again later? Would be good to not need to do many changes to the upstream code base or we'll have lots of work maintaining and rebasing. Regards, Tomeu - Eben - implement your design in activities-devel.sugarlabs.org and ask the community for opinions before applying those changes to production. AFAIK, you will only need to modify two files in order to customize the look of the site: http://git.sugarlabs.org/projects/slo-addons/repos/mainline/blobs/devel/site/app/webroot/css/sugar.css http://git.sugarlabs.org/projects/slo-addons/repos/mainline/blobs/devel/site/app/webroot/img/sprite.png Regards, Tomeu On Thu, Feb 19, 2009 at 17:10, ,Josh williams joshcwilli...@gmail.com wrote: Hi, I'm working on the design of sugar labs add-ons with Mick Weiss. I've created a mock up at http://sugarlabs.org/go/AddonsPortal/Design but I've haven't been able to contact anyone on the design team as of yet. I would also like to volunteer some of my time for other projects. I'm primarily a front-end designer with XHTML/CSS JavaScript skills, but I also know some PHP/MySQL and have a background in Linux. I also enjoy creating icons, so if there are any activities developers that need icons please contact me. My
Re: [IAEP] [Sugar-devel] design team meeting (And finding a new regular time)
I wasn't available for a meeting today, so that's partially my fault. I'm trying to get back into the swing of things, though, and actually had the chance to meet with Christian today regarding starting up regular design meetings again. As our work on Sugar will be voluntary, we both feel that selecting a time on the weekends (or perhaps late evening, though naturally timezone complicates this) may allow us to attend regularly as we'd like to. Would this work for others with interest? What days/times would be most suitable for everyone? - Eben On Thu, Feb 19, 2009 at 10:47 AM, Tomeu Vizoso to...@sugarlabs.org wrote: Hi, no meeting today? Regards, Tomeu ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] feature freeze issue #2: making easier for people to title their activities
On Sun, Jan 18, 2009 at 12:55 PM, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: On Sun, Jan 18, 2009 at 12:20:29PM -0500, Eben Eliason wrote: [Don't keep option in Naming dialog that pops up when closing the activity] Honestly, I think we'll make a lot of people happier by offering this option. Please don't do this. The Save/Discard dialog that traditional applications show on close is a recipe for disaster. Please add an explicit Discard action to the activity menu instead. There's a paper (from a friend of mine) discussing this in detail, but unfortunately it's in german only currently. Yes, you're actually right, and it's the reason Sugar was initially designed without the need for manual saving at all. You raise a good point. Perhaps we can add a secondary option to the Stop button for this instead, which forces a conscious decision before a dialog is needed. (This is fine, since the default is to keep automatically) How about Stop and discard, or maybe just Discard? This has some implications, though, since it makes this option available all the time, instead of just for new instances. If you choose discard when you've previously resumed, what happens? The logical answer in ideal Sugar is that you simply discard changes, but retain any previous versions. Since we don't have versions, do we just discard changes, effectively reverting? Maybe Discard changes is a bettter description. - Eben CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBSXNs9Lpz82VMF3DaAQL1NQgAjEcXfX99rIqVIezeGLHrvmQwjxuuiTm7 oqtvChYqc+WuBgp3GLlOslQcTukhn20Jba/cjm2yewBrACj7Pa7gIY2n9dDpwgD3 tPr8EWxg6+Pocuq1Yj+83AyPqepRkB0k8tsknMPRMWDl3rlpTsfTen0Db+F8SpP/ 11+gVmut3frZFHlJQsNrWJ+QnL2/9PkXExlOLDFZbZ/TjzQ/PIzYymmWuVYC3Gct iESLBTtGhXZS0ZhBqVqhzcmfcXsiqJ8f6JxTJEyMFJt4GhDzLjOFKQJjQbsYKmIK sz5a9L4dw+FH/RWt0oS498VrmSYbPRXoO2UxhPEVvFj5eifZ6jebvA== =K1m2 -END PGP SIGNATURE- ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] Moving on, moving forward.
Good afternoon to all, Tomorrow marks my last day as an OLPC employee. My experience here has been incredible, and I'm extremely grateful for having had the opportunity to work on such an ambitious project, which will no doubt have a profound affect on the lives of children worldwide, and on education in general. It's also been a pleasure working will all of you—some of the brightest and also some of the most generous folks I've met. I sincerely hope that we'll remain in touch. To those at Sugarlabs, I wish to indicate my intent to remain involved in the project to the extent possible in the months and years to come. I believe strongly in the value of what we've been trying to accomplish, and hope to see (and help) it reach the potential we all know it has. We've done much, but there's a long way to go. I'll do the best I can to remain active in the lists and IRC channels, and to be responsive to needs of the community with regard to future design work. I also plan to continue the bi-weekly design call (though it will need to be rescheduled) in order to remain in touch moving forward. To those who remain at OLPC, thank you for being part of a fantastic and dedicated team, of which I'm proud to have been a member. I wish all of you the best in whatever lies ahead there. I also know that many of you have shared in enthusiasm for Sugar, and many have great ideas that would be greatly missed if forgotten. I hope that, despite OLPC's release of Sugar to the community, those of you continuing with OLPC can find time to remain in touch with that community and continue to bring your talent and ideas to the project. Finally, to those who will also be leaving OLPC tomorrow, I wish you all the best in the future, and hope that you, like me, can be as happy to have been a part of this project. - Eben PS. Of course, if anyone has contacts or knows of opportunities in the design community (interface, interaction, experience, graphic, web, or otherwise) I'd be more than happy to be given some pointers as I try to find my next direction. Thanks. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] TestingTeam - Bugsquad
On Fri, Dec 12, 2008 at 5:55 AM, Simon Schampijer si...@schampijer.de wrote: Hi, we agreed in the QA-Meeting to rename the TestingTeam to Bugsquad [1]. Can someone with wiki powers move TestingTeam/* to BugSquad/*? Hmmm, the name change seems to imply something slightly different, to me. I had hoped that the TestingTeam (in addition to direct testing of builds) would coordinate usability testing either themselves, or reach out to many volunteers who have been interested. However, BugSquad seems like entirely the wrong name for that effort, and might not be found at all by someone coming in from the outside looking to help. How can we reconcile this? - Eben PS. In general, BugSquad sounds like the people handling the pest problem: triaging, generating reports, etc; not those in charge of finding bugs. But maybe that's just me. I must apologize, of course, for questioning, since I wasn't present at the meeting to hear the arguments from both sides. ;) Thanks in advance, Simon PS: I know BugSquad does not fit in the Team terminology but BugTeam sounds awful and anomalies are nice :) [1] http://lists.sugarlabs.org/archive/sugar-devel/2008-December/010291.html ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Branding and mascot (Was: Re: Color combos for the logo)
On Fri, Dec 5, 2008 at 11:36 AM, Gary C Martin [EMAIL PROTECTED] wrote: On 5 Dec 2008, at 12:17, Jameson Quinn wrote: 3. Personally, I'd love a mascot too; kids like cuddly. My initial brainstorms: associated with sugar? Pollinators (nectar) Hummingbirds (too western-hemisphere) Bats (anything nocturnal is culturally dangerous, but I love 'em) Bees (good possibility) flies (yuck) ants (has good community associations) gingerbread man (cute, but a little too gendered and shrek-y) bears (too generic) sugarcane fieldworker (yeah, right) I just googled and OMG WE HAVE A WINNER as far as I am concerned. That is cute beyond words and it is called a sugar glider. I'd never heard of that name even though my mom's Australian but it is beyond my wildest dreams. What do other people think? Cute :-) But it needs to work as a 2 colour (+ alpha) icon at large and small sizes all over the UI. The XO really is a very well chosen design element... If we really can't keep it, well, my best thought so far is to make something very similar/stylised, some other kid like stick figure shape or perhaps face. Needs a lot of thought. I'd strongly recommend against eliminating the XO as the core element of the UI. It was chosen specifically to represent children, and to maintain the human/body metaphors where appropriate. Substituting it with anything other than a human likeness would be counterproductive, I fear. I'm fairly confident that, though we can't use it as a brand identity, we can keep that icon in the UI itself. - Eben --Gary ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Branding and mascot (Was: Re: Color combos for the logo)
On Fri, Dec 5, 2008 at 1:12 PM, Kevin Cole [EMAIL PROTECTED] wrote: On Fri, Dec 5, 2008 at 11:45, Eben Eliason [EMAIL PROTECTED] wrote: I'd strongly recommend against eliminating the XO as the core element of the UI. It was chosen specifically to represent children, and to maintain the human/body metaphors where appropriate. Substituting it with anything other than a human likeness would be counterproductive, I fear. Is it possible to split the difference? It seems to me that by adding wings of a sort to the XO figure, you'd be able to approximate something that still looks human, yet also looks like a sugar glider -- or a kid with a hang glider. Clearly related to the original, but like the Red Bull commercials say Sugar gives you wings! ;-) I don't think so. That misses the point, which is that the children themselves—not flying squirrels, however cute ;) —are represented as a fundamental part of the interface. - Eben -- Ubuntu Linux DC LoCo Washington, DC http://dc.ubuntu-us.org/ ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Branding and mascot (Was: Re: Color combos for the logo)
On Fri, Dec 5, 2008 at 1:32 PM, Eben Eliason [EMAIL PROTECTED] wrote: On Fri, Dec 5, 2008 at 1:12 PM, Kevin Cole [EMAIL PROTECTED] wrote: On Fri, Dec 5, 2008 at 11:45, Eben Eliason [EMAIL PROTECTED] wrote: I'd strongly recommend against eliminating the XO as the core element of the UI. It was chosen specifically to represent children, and to maintain the human/body metaphors where appropriate. Substituting it with anything other than a human likeness would be counterproductive, I fear. Is it possible to split the difference? It seems to me that by adding wings of a sort to the XO figure, you'd be able to approximate something that still looks human, yet also looks like a sugar glider -- or a kid with a hang glider. Clearly related to the original, but like the Red Bull commercials say Sugar gives you wings! ;-) I don't think so. That misses the point, which is that the children themselves—not flying squirrels, however cute ;) —are represented as a My apologies extend to the marsupials, should I have offended them with my ignorance. =) - Eben fundamental part of the interface. - Eben -- Ubuntu Linux DC LoCo Washington, DC http://dc.ubuntu-us.org/ ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Fwd: [OLPC-SF] Not new, but needs to be addressed
Good summary. On Wed, Dec 3, 2008 at 7:17 AM, Jameson Quinn [EMAIL PROTECTED] wrote: Here is my list of complaints from that evaluation, which was obviously using a 600-series OS version. not traditional desktop metaphor Fact. no tabbed browsing I have a proposal for this which I've been meaning to mockup. I'm adding it to my todo list now. flaky wireless A lot better, these days. some bad machines: difficulty turning on and peeling mousepad. flaky mouse has a mouse instead of mouse-alternatives (?) Hardware. (Still important, being worked on.) popup menus too slow This is something we should look into. Actually, we've slowed down their appearance since then, because we found that people were often waiting for the menu, instead of clicking directly on the icon/button directly. We've also added the right-click to reveal the palette immediately. I think the current state is reasonable, but more feedback on this is welcomed. activity startup too slow Improving a little. see address in browser bar should be easier (fixed) Yup. hard to save to USB. Should be accessible from within an activity. Yup. scroll bars too small, especially for subsidiary panes (interesting issue for grab key, BTW) Right. The grab key continually eludes. I know Erik worked on it for a bit, but I don't know the current status or if it's possible to roll it into a build soon. If we aren't going to have the grab key, we truly are going to have to increase the size of the scroll bars. I may have missed a few, but I think that most of these are either already the focus of effort (and progress) or have been decided against by many here. The one I bolded is I think a useful one: why not have a keep to USB and keep to SD option in the keep dropdown menu in the activity toolbar? You're absolutely right, and that has definitely been the plan. External devices have never gotten any polish; hopefully as we redesign the manner in which they work and interact with the Journal we can also add these types of features. - Eben Jameson On Wed, Dec 3, 2008 at 2:53 AM, Edward Cherlin [EMAIL PROTECTED] wrote: FYI. -- Forwarded message -- From: Valerie Taylor [EMAIL PROTECTED] Date: Mon, Dec 1, 2008 at 7:13 AM Subject: [OLPC-SF] Not new, but needs to be addressed To: [EMAIL PROTECTED] This just in from a well-meaning colleague who was using XOs. There are lots of issues identified here. There is a serious failure-to-communicate. These are real concerns for many people and this is what they hear. It is easy to dismiss this as Leigh's problem, but it isn't his alone. Everyone of us associated with OLPC needs to do a better job at bridging this gap. Are there good sources of information that address these issues and guidelines that would ease the transition from PC to XO in situations like this? http://learnonline.wordpress.com/2008/12/01/my-experience-with-olpc-in-tuvalu/ ..Valerie ___ OLPC-SF mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/olpc-sf -- 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/User:Mokurai ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Fwd: [sugar] Closing this list
On Wed, Nov 26, 2008 at 4:24 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: Could someone help with Morgan suggestion? Related to his suggestion, there is a deployment team on the wiki, and a sugar-devel list. A few questions follow: 1. Should we have a list for each team? Eg. should there also be a sugar-design list, etc.? This might be useful for announcing meetings. Also, having a list in the contact section for each team would make sense. I know that we strive not to split lists unnecessarily, but it seems to me that the team divisions are fairly clear, and it would actually make sense to cross-post when a subject involved several teams. 2. Do we really need to preface the lists with sugar-; isn't @lists.sugarlabs sufficient enough to indicate context? It seems we might also have [EMAIL PROTECTED], [EMAIL PROTECTED], etc. All of these relate to sugar, but the prefix seems redundant. - Eben Thanks, Marco -- Forwarded message -- From: Morgan Collett [EMAIL PROTECTED] Date: Wed, Nov 26, 2008 at 9:53 AM Subject: Re: [sugar] Closing this list To: Marco Pesenti Gritti [EMAIL PROTECTED] Cc: Sugar Mailing List [EMAIL PROTECTED] On Wed, Nov 26, 2008 at 10:38, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: Hello, as previously announced we have a now an upstream mailing list for Sugar development: http://lists.sugarlabs.org/archive/sugar-devel/ My suggestion would be to close [EMAIL PROTECTED] and have the few distribution specific discussions in [EMAIL PROTECTED] *If* there is full consensus we might also consider to copy the subscriber list of [EMAIL PROTECTED] to [EMAIL PROTECTED] +1 from me. What might help is to list the lists in a discoverable place on the wikis, showing clearly which list is appropriate for what, since we are getting support questions on iaep etc. Regards Morgan ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Teacher in OLPC-Sur list enchanted to see his idea, integrated into global Sugar
On Tue, Nov 18, 2008 at 11:14 AM, Greg Smith [EMAIL PROTECTED] wrote: Hi Pato (espero que no le molesta si uso este nombre), I'm revisiting an older thread. I read your blog and I think its great! Congratulations to you and Walter for implementing this and closing the loop all the way back to the classroom. I want to see what we have learned about developing software that is relevant and useful for teachers. I especially want to learn how to make this happen more often and with more people (programmers, students and teachers) involved. I see you have requested two more things: 1.- A Beep function in TurtleArtwithsensors. 2.- A easy way for to write Hello word. I received a report about uruguayan?s kids writing letters with the turtle?s lines, but this way is slow and not fun. It seems to me that a line (or perhaps a circle) is the the hello world of Turtle art. I'm curious as to the intent of the request, though. Is the desire to write hello world specifically due to cliche, or is it instead to support textual output in Turtle Art in general, perhaps by drawing text at a given coordinate, or along a path? Indeed, I'd agree that programming the turtle to write hello world with turtle lines is far beyond the intended scope of a hello world exercise! I wonder what forms (those I mention above? others?) of textual output people would find useful or engaging in this environment. - Eben These look little more challenging than square root to me :-) I think they also need better definition to fully understand what you need. I believe that Walter has taken over maintenance of the Turtle Art program and that he plans a new release soon. You may want to follow up with him to see if he can get these in a future release. They may need some more definition (e.g. are you asking for these to work a particular school or class? what are you going to teach with these features in TurtleArt? when, how and why do you want to put text in the program etc.) I'm interested in the details but I think its really up to you and the programmers (Walter in this case). So I'll just watch if you don't mind working this out on the list. BTW I also noticed and followed up on this related thread on the Sur list: http://lists.laptop.org/pipermail/olpc-sur/2008-October/001145.html Thanks, Greg S ** Hi Greg: TurtleArt-11.xo worked perfectly. My report with teacher?s comment, screenshoots, and pedagogical support (only in spanish) here: http://patricioacevedo.blogspot.com/2008/09/mi-reporte-para-sugar-labs.html I want to try this features: 1.- A Beep function in TurtleArtwithsensors. 2.- A easy way for to write Hello word. I received a report about uruguayan?s kids writing letters with the turtle?s lines, but this way is slow and not fun. Thanks Pato Acevedo www.patricioacevedo.blogspot.com Hi Luis, I believe that Walter updated TurtleArt with a square root function to address this. Was that a satisfactory response? Let us know how that worked for you and the people who requested it. Any comments or input appreciated. What else do teachers and users need? Let's see if we can address some more requests and start to improve the quality of the dialog at the same time. Walter, Essentially the same questions for you. Did that go the way you wanted? I get the impression you wanted teachers to modify the code themselves. Maybe you can elaborate on that. Perhaps you could have asked if anyone wanted to learn how to do it. In the cycle of praxis, there's the action and the reflection. If we're done with the action on this one (still want to hear the final ack) then a little reflection may be in order until we pick the next small challenge. At the same time we can think about what tools work best to address these in the future. I didn't see the bug ID come through dev.laptop.org but I may have missed it. I assume IRC didn't work for Luis either... Thanks, Greg S Date: Wed, 17 Sep 2008 17:24:27 + From: luis ACEVEDO [EMAIL PROTECTED] Subject: [IAEP] Teacher in OLPC-Sur list enchanted to see his idea integrated into global Sugar update [First approach] To: iaep@lists.sugarlabs.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 Hello: My name is Luis Acevedo, live in Santiago, Chile. I participate actively in the mailing list OLPC-Sur and is closely monitoring the mailing list Sugar Labs. Yesterday in the Sur- List we had a report about a required feature for Turtle art activity. This is root square function. Teachers found necessary this function in activities like figure 28 and others from this page http://neoparaiso.com/logo/ejercicios-de-geometria.html I suggested to obtain a ticket trac in http://dev.laptop.org/ and to try in the irc channel. Is there a other way like to contact directly the authors? Is this a correct place
Re: [IAEP] Teams - Time to grab a team
I'll own Design. I promise I'll get back to regular meetings and thorough minutes! - Eben On Sat, Nov 8, 2008 at 5:33 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Sat, Nov 8, 2008 at 11:28 PM, David Farning [EMAIL PROTECTED] wrote: As long as we are putting our time where our talk is I'll serve as the WikiTeam coach. I have scheduled a meeting on the Sugar Labs community calendar at http://www.sugarlabs.org/go/Community . I can take Development. I'm tempted to merge Development and Release though, since at our current scale I'm not convinced we need to keep the two separated. Marco ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [sugar] Narrative.
On Thu, Oct 9, 2008 at 11:28 AM, Brian Jordan [EMAIL PROTECTED] wrote: On Thu, Oct 9, 2008 at 4:57 PM, Michael Stone [EMAIL PROTECTED] wrote: Bill, Here's a short dialogue between myself, Ben Schwartz, Martin Dengler, and Bobby Powers on my interpretation of narrative as it might apply to a user interface designed for engaging children in the world of learning: http://wiki.laptop.org/go/User:Mstone/Commentaries/Sugar_2 My favorite part was the end: bemasc making content bundles work better sounds very valuable. We certainly don't provide nice content creation tools. I heartily agree that this is an area in which improvements are worth pursuing. m_stone lovely. now if only you weren't in engaged in pursuit of further education... :) bemasc right. === Highlights * By narrative, I mean a rational sequence (or graph) of events. * It's rather hard to use XOs to prepare direct lessons. By direct lesson, I mean a guided learning experience, usable in variable network conditions, which minimizes the amount of decision-making and navigation that the end-user needs to perform in order to experience 'the whole thing' regardless of what software implements each individual experience contained in the lesson. === Toy Problem Concretely, suppose I invent a new Python trick like the ones at http://wiki.laptop.org/go/User:Mstone/Tricks How might a prepare a slick explanation for an inexperienced user? * I might write up a web page for my trick, then write a Pippy bundle showing off the trick in a toy program, then give a pointer to a git repo containing an instance of the trick in 'production'. Question: How do I write web pages on an XO? Question: Do I have to be able to read in order to find and run the Pippy bundle? * I might write up a larger Pippy example for my trick in the literate style. I might also create a puzzle revolving around integrating the trick into some sample code. I might include links to 'advanced reading' or more examples in comments in the source code. Question: Pippy doesn't know anything about hyperlinks. Will my readers? Question: I must either comment out my puzzle so that the example can run or I must provide it in a separate bundle. How many users would figure out how to try both the example and the puzzle? * While not obviously applicable to this specific example, two other common solutions to this sort of problem include the scripted transitions between freeform experiences idea common to wizards and role-playing games and the 'build a custom but user-editable program' idea underlying most EToys lessons. === Larger Concerns Since Sugar is strongly concerned with UI unification, it's worth spending more time thinking about how well each of the solutions to your favorite toy problem integrates with encompassing narratives of reflection, criticism, and human collaboration. (None of the solutions I've proposed above satisfy me in any of these regards.) In any case, I hope this followup helps explain the motivation and 'line-of-thought' behind my initial email. Please discuss. Regards, Michael ___ Sugar mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/sugar So, how about (1) a way of creating content bundles with journal content created on the XO, and (2) a way of transferring these bundles and journal items from XO -- XO without having to use a USB key? We've always envisioned (1) as an activity (The Bundle activity, in fact), which would serve both as a way of creating and managing activity and content bundles, as well as provide a generic tool for inspecting , modifying, or creating various type of archived format (zip, tar, gz, etc). Also, please note that Lewis Barnett (CC'd), a professor from the University of Richmond, has adopted this project and is working on it as a class initiative. I had a teleconference with some of his students several weeks ago to discuss initial details, and I'm excited about what we can accomplish with them. I haven't heard from them since, and I'm not sure if a project has been setup for them yet. Perhaps you could give us a breif status update, Lewis? Thanks! (2) Should be handled like any other object transfer between XOs, which hasn't been built yet, but is certainly on the list of needed features. There is, of course, special consideration to be given to the passing of activity bundles, a la the former discussions on implicit sharing, trusted code, etc. - Eben Does (2) currently exist (outside of terminal), by the way? Could (1) and (2) be done as activities? Regards, Brian ___ Sugar mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/sugar ___ IAEP -- It's An
Re: [IAEP] Teacher in Uruguay enchanted to see his ideas integrated, into global Sugar update
. Nonetheless its necessary input which tells us what they are most interested in doing. Interesting ideas. We also need to consider which of these fall under Sugar, and which do not. The first suggestion is clearly activity specific. We should be making downloads and uploads easier, for sure (I think we went a LONG way toward uploads with this release, too!). Moving data from XO to XO is on the sugarlabs goals page also, but I believe you pushed it into the unwanted features section. I want to make sure that all of our work is grounded in specific requests and user goals. That has to come first before we design code or GUIs. Part of my work is to explain what is most important to users so I apologize for falling behind on making that clear. As usual, engineering has gotten ahead of me. I did post a few ideas on the file moving area here: http://wiki.laptop.org/go/9.1.0#File_Management We urgently need to listen to the input we have so far. Everything we do must be tied to a high level goal and to specific input and users. That is my most fundamental request! Sounds good. Thanks for the guidance so far. - Eben BTW I'm not trying to cast aspersions on your work. The 8.2 release has been getting great reviews with respect to the new GUI. Its by far the strongest new feature set in the release. Thanks, Greg S PS sorry for the long e-mail. Not time to edit as we need to make a real release candidate for 8.2 ASAP! Eben Eliason wrote: On Thu, Sep 18, 2008 at 4:19 PM, Greg Smith [EMAIL PROTECTED] wrote: Hi Eben, There's already a lot of feedback. Start sifting :-) Please post anything you aggregate and think we should work on to the 9.1 page: http://wiki.laptop.org/go/9.1.0 None of us have time to aggregate, if we even find out where we might pull info from. That's the point I'm getting at. I want a way to make this info readily accessible to everyone, without devoting half of my week to scouring scattered sources. That could be a full time job. Also, I'm not sure that aggregating on the 9.1 page is a good solution. That's a good way for a lot of good feedback to get lost in 6 months. I'd rather have a mailing list, or forum, or some other form of database from which we can reference individual responses on trac tickets, so that the feedback can live on as a reference in a place we won't lose it. A mailing list sounds like the easiest solution, at least short term. - Eben ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Teacher in Uruguay enchanted to see his ideas integrated, into global Sugar update
On Thu, Sep 18, 2008 at 4:19 PM, Greg Smith [EMAIL PROTECTED] wrote: Hi Eben, There's already a lot of feedback. Start sifting :-) Please post anything you aggregate and think we should work on to the 9.1 page: http://wiki.laptop.org/go/9.1.0 None of us have time to aggregate, if we even find out where we might pull info from. That's the point I'm getting at. I want a way to make this info readily accessible to everyone, without devoting half of my week to scouring scattered sources. That could be a full time job. Also, I'm not sure that aggregating on the 9.1 page is a good solution. That's a good way for a lot of good feedback to get lost in 6 months. I'd rather have a mailing list, or forum, or some other form of database from which we can reference individual responses on trac tickets, so that the feedback can live on as a reference in a place we won't lose it. A mailing list sounds like the easiest solution, at least short term. - Eben In addition, a feedback activity seems like an easy short term win. Could be posted and shared quickly and easily. If it gets traction it would help motivate a solution built in the core OS/UI. Thanks, Greg S Eben Eliason wrote: On Wed, Sep 17, 2008 at 12:53 PM, Greg Smith [EMAIL PROTECTED] wrote: Hi All, On this: Perhaps you would be interested in http://dev.laptop.org/ticket/6950. I think all these things would go together nicely. Changed 2 months ago by gregorio milestone deleted Milestone Never Assigned deleted When I started at OLPC one of the first things I did was clean up the roadmap in Trac. There were a handful of vague may want to do it in the future milestones. I deleted a few of those before I realized that it would also remove them from the bug IDs. That's why you see these messages. We do need to figure out where to put it on the roadmap and I'm not opposed to this idea. On the subject of gathering input from users its been a recurring theme of the lists and I have commented on it several times. Its an important problem which we must grapple with. Initially I thought we need more input and information. Then in December I started to realize how much input is already available. I collected some of them on my talk page at: http://wiki.laptop.org/go/User_talk:Gregorio There are wikis, forums, moodles and other sites already full of suggestions and comments about the product. Aside from the ones on my talk page I can mention - Moodle out of Peru: http://www.innovavirtual.org/moodleperu/ - Forum in Uruguay http://www.mediagala.com/rap/foro/ - Our OLPC forum http://en.forum.laptop.org/ and of course the olpc-sur list. This is fantastic; was I among few who didn't know of their existence? I might be, but we could probably do a better job exposing this kind of information. Also I understand that kids in Uruguay and elsewhere have been downloading this activity: http://wiki.laptop.org/go/XoIRC and it has a default channel which has been very active. There is also a spanish IRC channel which has seen a lot of use. Even the question of which is the right tool to gather more suggestions is something we should ask people to suggest! If you want people to give input, its better to ask them what works best for them than to decide that yourself. I have been mulling over the best communication channels with Pablo out of Uruguay for 9 moths and we still don't have a definitive answer. For me, the question is not so much how do we gather more input as how do we respond to the input already expressed. I think this misses a very crucial element, which is locating/aggregating the data. If there's no channel through which the data can be collected, searched, or organized, we have little hope of responding to it. The main reason I think that something in the realm of a Suggestion Box activity is needed is not *only* so that kids and teachers have a place to express their thoughts, but just as much so that their efforts can be collected and reviewed by all who are interested, in a common place. (Which, in turn, should ensure that their thoughts are more likely to effect change.) The requests do not generally come in like: I want a button on the right. The people using the XO are teaching or learning so the request is usually more like: its too slow make it faster or I need better tools to teach geometry. See the Sur list for some comments like that. This is true, of course. It could lead to a lot of feedback, much of it not succinct or strictly targeted, but at least we'd have it in a place where all can find it. If our biggest problem is sifting through *too much* feedback, then we're in good shape. Let's find a way to put it all to good use! - Eben After an intial suggestions, you need a further discussion befoe it gets to exactly what code needs to be written. In terms of how we engage that dialog, I wrote a brief explanation of how I think it should work
Re: [IAEP] Sad
On Wed, Sep 17, 2008 at 6:50 AM, Albert Cahalan [EMAIL PROTECTED] wrote: In my previous email I probably strayed too far from my main point: as long as we remain oblivious to deficiencies and insist on staying the course, we're handing kids to Microsoft. It's damn hard to step back and see things as others do, especially after spending tons of effort on cool new ideas. I don't think any of us are oblivious. For one thing, despite some obvious deficiencies, kids are actively engaging with the software and exploring new ways to learn. That's a Good Thing. That aside, the reason you don't hear us whining every chance we get is because we're actively focusing that energy into improving the code, the design, the OS, and the experience for all (including us) using the software. Yes, there are bugs. Yes, there are unimplemented features. Yes, there are some aspects of the design, all the way through the stack, that we might have to adjust. But we're working on it. If you think any of us are content with the software we're presently shipping, you're dead wrong, so please don't incessantly shout at us from the sidelines as though we're all blind. You insinuate that staying the course implies we are oblivious to deficiencies, which is simply untrue. If our only goal was to ship a non-MS OS, that might be the case, but as Bert stated, that is not the goal. There is presently no other OS designed from the ground up for kids, for exploration, for collaboration, for learning. Our only course of action is to do everything we can to make that vision a reality, and we're working darn hard at it. - Eben ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Teacher in Uruguay enchanted to see his ideas integrated, into global Sugar update
On Wed, Sep 17, 2008 at 12:53 PM, Greg Smith [EMAIL PROTECTED] wrote: Hi All, On this: Perhaps you would be interested in http://dev.laptop.org/ticket/6950. I think all these things would go together nicely. Changed 2 months ago by gregorio milestone deleted Milestone Never Assigned deleted When I started at OLPC one of the first things I did was clean up the roadmap in Trac. There were a handful of vague may want to do it in the future milestones. I deleted a few of those before I realized that it would also remove them from the bug IDs. That's why you see these messages. We do need to figure out where to put it on the roadmap and I'm not opposed to this idea. On the subject of gathering input from users its been a recurring theme of the lists and I have commented on it several times. Its an important problem which we must grapple with. Initially I thought we need more input and information. Then in December I started to realize how much input is already available. I collected some of them on my talk page at: http://wiki.laptop.org/go/User_talk:Gregorio There are wikis, forums, moodles and other sites already full of suggestions and comments about the product. Aside from the ones on my talk page I can mention - Moodle out of Peru: http://www.innovavirtual.org/moodleperu/ - Forum in Uruguay http://www.mediagala.com/rap/foro/ - Our OLPC forum http://en.forum.laptop.org/ and of course the olpc-sur list. This is fantastic; was I among few who didn't know of their existence? I might be, but we could probably do a better job exposing this kind of information. Also I understand that kids in Uruguay and elsewhere have been downloading this activity: http://wiki.laptop.org/go/XoIRC and it has a default channel which has been very active. There is also a spanish IRC channel which has seen a lot of use. Even the question of which is the right tool to gather more suggestions is something we should ask people to suggest! If you want people to give input, its better to ask them what works best for them than to decide that yourself. I have been mulling over the best communication channels with Pablo out of Uruguay for 9 moths and we still don't have a definitive answer. For me, the question is not so much how do we gather more input as how do we respond to the input already expressed. I think this misses a very crucial element, which is locating/aggregating the data. If there's no channel through which the data can be collected, searched, or organized, we have little hope of responding to it. The main reason I think that something in the realm of a Suggestion Box activity is needed is not *only* so that kids and teachers have a place to express their thoughts, but just as much so that their efforts can be collected and reviewed by all who are interested, in a common place. (Which, in turn, should ensure that their thoughts are more likely to effect change.) The requests do not generally come in like: I want a button on the right. The people using the XO are teaching or learning so the request is usually more like: its too slow make it faster or I need better tools to teach geometry. See the Sur list for some comments like that. This is true, of course. It could lead to a lot of feedback, much of it not succinct or strictly targeted, but at least we'd have it in a place where all can find it. If our biggest problem is sifting through *too much* feedback, then we're in good shape. Let's find a way to put it all to good use! - Eben After an intial suggestions, you need a further discussion befoe it gets to exactly what code needs to be written. In terms of how we engage that dialog, I wrote a brief explanation of how I think it should work at: http://wiki.laptop.org/go/User:Gregorio We're now engaged in the practice of it and we need that piece along with the theory to get it right. In terms of building in a please fix it button, I'm in favor of that. I think it should be an activity not a piece of the OS until we can prove the concept and show that we can collect good feedback, generate a meanigful dialog and most importantly respond in a constructive way to the requests. Lastly, if a user has asked for something which is documented and well defined and we think it should be built then go ahead and put it on the 9.1 page: http://wiki.laptop.org/go/9.1.0 I just ask that you sign it or put it on the talk page. To Christoph's original point. They already asked, now we need to deliver on that. How about starting with this one: http://wiki.laptop.org/go/9.1.0#Touchpad or this one: http://wiki.laptop.org/go/9.1.0#Longer_Battery_Life :-) I hope that's constructive. I want to see more feedback and more responsiveness to requests. My main point is that the ball is in our court. Once we find people to engage with the only way to get there is with a rich dialog where we learn about the users and they learn about building software.
[IAEP] Announcing biweekly design meetings
To the designing and implementing masses: I'm happy to announce that, beginning this week, I will begin hosting a biweekly open design meeting on IRC. Though targeted at the core sugar team and activity developers, all interested are more than welcome to attend. We will focus on high level design discussion and planning, feedback and analysis of current designs (both successes and failures), and occasional reviews of new visual design proposals. * Biweekly, 1st and 3rd Thursdays * 15.30 UTC [1] * irc.freenode.net, #sugar-meeting For more information, and to preview or suggest agenda items, please see http://sugarlabs.org/go/DesignTeam/Meetings. - Eben [1] Convert UTC to your local time: http://www.timeanddate.com/worldclock/converter.html?hour=11min=30sec=0p1=0p2=43 ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Teacher in Uruguay enchanted to see his ideas integrated into global Sugar update [pr mockup]
I'm not sure if this should be an integrated part of the OS, or a separate activity, but let me propose a view of the latter: Suppose we create a Suggestion Box activity, which offers a streamlined interface for providing suggestions. Have the suggestions all get sent to, for instance, [EMAIL PROTECTED] Or, if you want to split based on language, [EMAIL PROTECTED] Then we'll have a repository of all the feedback and suggestions that come in readily accessible, archived, and searchable, and we can discuss them in place on the lists, and break things out into trac tickets as needed. As an addendum to this idea, I'd really like to see the Log activity gain similar support, so that in addition to offering a view of logs, it provided a way to send feedback reports, automatically including necessary data such as serial number, build number, hardware, etc. This would also make it really easy to attach logs to feedback. It should be possible to send logs to the right people, according to a URL in the activity.info file for each. Finally, if people are really ambitious, what we really need is this: http://mydreamapp.com/contestants/view/kevincapizzi/idea/ . Call it the Discuss activity. The idea is to create a simple streamlined interface through which to interact with any online forum you subscribe to. We could pre-populate this with our support forum, and create forums for suggestions, logs, and other needs as well. This, I feel, could be fantastic. - Eben On Tue, Sep 16, 2008 at 5:45 PM, Christoph Derndorfer [EMAIL PROTECTED] wrote: Mmmm, I know I'm being the cranky one here today but I can't be the only one thinking that IRC (or any activity based on it) isn't all great a solution. Even for an immediate stop-gap solution it sucks. A lot. As C.Scott mentioned we really need two solutions: a social one and a technological one. For the social one we need to get people to deployments. For the technical one we need to find the easiest possible way for people to get comments, suggestions, ideas, rants from wherever they are to this list and other appropiate places. Here's my current thinking: Screw the non-existant Show me the code functionality and turn this into kick a developer's ass button;-) Seriously, also with regard to the recent Windows XP in Peru announcement what we need to do is offer a competitive advantage to such a solution. I know I being a pain about a this but I truly believe that a well-established feedback-loop between deployments and developers is one of the key USPs here. At the end of the day this is of course a major decision in terms of Sugar Labs' scope. Personally, I'm still a fan of a very early message by Ivan K. which specifically asked for Sugar Labs to be more than just a software outfit... Anyway, 'nuff said for a day, Christoph Zitat von Walter Bender [EMAIL PROTECTED]: All very good points. At the time, there were a number of issues we hadn't resolved: what channel to default to ; what to do at the back end in terms of manning the channel(s); what to do about language -- not of the tool, but the discussion; (now that we have the Sugar Control Panel, some of these are all less of an issue) etc. -walter On Tue, Sep 16, 2008 at 4:21 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: On Tue, Sep 16, 2008 at 4:08 PM, Walter Bender [EMAIL PROTECTED] wrote: The XoIRC Activity was designed for exactly that. Can we dust it off and improve it then? It's not translated, it requires kids to type in obscure irc commands (/msg, etc), and there's no way to 'leave a suggestion' that persists. The title 'XoIRC' doesn't mean 'go here to get help or make a suggestion' in any language I know of. --scott -- ( http://cscott.net/ ) -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com e-mail: [EMAIL PROTECTED] ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
