Re: [Sugar-devel] [DESIGN] Sugar Journal - Erase confirmation
On Tue, Sep 21, 2010 at 4:18 PM, Walter Bender walter.ben...@gmail.comwrote: On Tue, Sep 21, 2010 at 10:11 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Mon, Sep 20, 2010 at 23:50, Samuel Greenfeld greenf...@laptop.org wrote: In Sugar's Journal, the per-entry Erase menu choice does not ask for any confirmation prior to deleting an object. This presents the risk of accidentally deleting something, especially since the View Details menu choice is immediately above it I searched bugs.sugarlabs.org looking to see if anyone had ever suggested verifying the erasure/deleting of a Journal entry prior to doing so, but could not find any obvious tickets on the subject. Does anyone know if this is by design? I don't really remember, adding Eben and Christian to CC in case they do. I don't remember either. We really should be asking to confirm, especially for user-generated data. But if and when someone digs into that code, it would be great to finally address the issue of selecting multiple objects. Deleting one item at a time, even without the additional step of a confirmation, is tedious. Agreed. I think the expectation there was that a confirmation dialog would appear in a strip beneath the toolbar, with Cancel and Erase buttons. I also agree with Walter regarding the need for multiple selection support; we had some nice mockups with checkboxes that enabled single-click (without modifier) selection of sets of objects to take action on. Eben -walter -walter Cheers, Tomeu --- SJG ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Putting stuff in the control panel vs. the frame
On Tue, Aug 3, 2010 at 11:51 AM, Christoph Derndorfer christoph.derndor...@gmail.com wrote: Hi all, looking at some of ParaguayEduca's latest builds I saw that they have added some new icons / features to the frame (e.g. CPU / memory consumption, accessibility, touchpad-mode, etc.) I talked to Bernie about this and we realized that there currently doesn't seem to be a clear consensus on what kind of features should go into the frame and which ones into the control panel. One could easily argue that some sparsely populated CP options could be removed and the options instead added to the corresponding frame devices (particularly power and network options come to mind here). Or on the contrary that things like the touchpad-mode should be accessed from within the CP rather than the frame. Anyway, I was wondering what people here thought about this issue. I think that the dominant factor in the choice of what to show should be the frequency with which the information or controls are used. If a setting is changed frequently by a child within a single session it's a good candidate for a device icon in the Frame. If the setting is, more often than not, set and then forgotten it should exist only within the Control Panel, where it won't distract from more important information and controls. I also agree with the idea Tomeu brought up; I think linking to the corresponding section of the Contol Panel from any devices that have additional settings makes a lot of sense. Eben Cheers, Christoph -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com e-mail: christ...@olpcnews.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Schoolserver icon
The door and the bell could both be solid stroke-colored fills. That would give it a simpler overall shape and likely allow the bell to be more legible at the size. Eben On Fri, Jul 2, 2010 at 7:41 PM, Gary Martin garycmar...@googlemail.comwrote: Hi Martin, On 2 Jul 2010, at 19:10, Martin Abente wrote: On Tue, 29 Jun 2010 21:53:59 +0100, Gary Martin garycmar...@googlemail.com wrote: On 29 Jun 2010, at 15:39, Martin Langhoff martin.langh...@gmail.com wrote: On Mon, Jun 28, 2010 at 6:57 PM, Bernie Innocenti ber...@codewiz.org wrote: El Mon, 28-06-2010 a las 21:36 +0100, Gary Martin escribió: A joke right? Something I missed from the early days? No joke! Sugar Labs is actually a masonic lodge. Oops, now I'll have to kill you. *I actually got questions about masonic influence on our UI design.* Not kidding... Anyway - there's a nice school at the 1 minute mark in this video - http://www.dailymotion.com/video/x7ft2t_olpc-mission-video-part-1_tech Thanks for the pointer, yea that works, a little like the top right 'with bell' attempt on my last sheet. I worried that one would be seen as too church like. I think that one looks really good :) Would you mind sending me the svg version? Sure. I've attached a SVG that is a (close) reproduction of the school with bell tower as shown in the OLPC promotional video (and similar to the top right icon from my previous email set). The one major change was to make proper use of fill and stroke colour, not just a single fill silhouette. The school-server icon needs to show colour identity in the neighbourhood, just like other objects. Martin (Langhoff): Can you confirm the server does pass some unique identity that could be used to set the icon fill and stroke identity colours? Sorry I don't know enough about the registration/ident. server process. Here's what it looks like in different colours at a small (close to neighbourhood view), and a larger size: Shout if you want changes/tweaks. Hope it's of use. Regards, --Gary Regards, --Gary m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Schoolserver icon
Ah, I see now. At first glance at the previous iteration I thought that it was just the stroke of a bell shape; I didn't read the bell within the arch. I do like that idea, actually, but this version does read more clearly. It looks great! I'm not sure if this would be any better or not, but have you tried a solid stroke-color cap on the steeple? You could also widen the steeple a bit to make the bell even larger for clarity. (These are just what ifs, though, not recommendations…it already looks great.) Eben On Fri, Jul 2, 2010 at 10:02 PM, Gary Martin garycmar...@googlemail.comwrote: On 3 Jul 2010, at 01:42, Eben Eliason wrote: The door and the bell could both be solid stroke-colored fills. That would give it a simpler overall shape and likely allow the bell to be more legible at the size. Eben Thanks for the feedback, good call! Regards, --Gary On Fri, Jul 2, 2010 at 7:41 PM, Gary Martin garycmar...@googlemail.com wrote: Hi Martin, On 2 Jul 2010, at 19:10, Martin Abente wrote: On Tue, 29 Jun 2010 21:53:59 +0100, Gary Martin garycmar...@googlemail.com wrote: On 29 Jun 2010, at 15:39, Martin Langhoff martin.langh...@gmail.com wrote: On Mon, Jun 28, 2010 at 6:57 PM, Bernie Innocenti ber...@codewiz.org wrote: El Mon, 28-06-2010 a las 21:36 +0100, Gary Martin escribió: A joke right? Something I missed from the early days? No joke! Sugar Labs is actually a masonic lodge. Oops, now I'll have to kill you. *I actually got questions about masonic influence on our UI design.* Not kidding... Anyway - there's a nice school at the 1 minute mark in this video - http://www.dailymotion.com/video/x7ft2t_olpc-mission-video-part-1_tech Thanks for the pointer, yea that works, a little like the top right 'with bell' attempt on my last sheet. I worried that one would be seen as too church like. I think that one looks really good :) Would you mind sending me the svg version? Sure. I've attached a SVG that is a (close) reproduction of the school with bell tower as shown in the OLPC promotional video (and similar to the top right icon from my previous email set). The one major change was to make proper use of fill and stroke colour, not just a single fill silhouette. The school-server icon needs to show colour identity in the neighbourhood, just like other objects. Martin (Langhoff): Can you confirm the server does pass some unique identity that could be used to set the icon fill and stroke identity colours? Sorry I don't know enough about the registration/ident. server process. Here's what it looks like in different colours at a small (close to neighbourhood view), and a larger size: Shout if you want changes/tweaks. Hope it's of use. Regards, --Gary Regards, --Gary m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Simple Journal Backup Restore Control Panel
Hello, I realize it's been a while since this was discussed, but I figured I'd share some thoughts, in no particular order before I archived the thread. • Having a settings module for this seems reasonable. It might be more fitting to just call it Journal Backup instead of Management, since it is exclusively for this function. I could see adding any pertinent versioning settings here as well in the future, even with the more specific name. • It could also be nice to have a Back up now option in the Journal palette. I don't think it's necessary to expose the restore action in the palette, though. • The icon looks reasonable, though using the fullscreen icon in this context is somewhat confusing. It might be better to use the keep icon, with bidirectional arrows, to maintain the visual language there. • The large clickable buttons are nice. I think in this instance it would be even better to have nice large up and down arrows to further emphasize the actions. The ones that were made for the 3G device traffic could work in this context, too. • I think this might work better as a two column layout, with backup on the left and restore on the right, with accompanying text and information. As it stands, the description is a bit far removed from the actual buttons, making it look more like the buttons are one unit and the descriptions are a second unit, instead od relating the description to the button. • I would change the label to Back up now instead of Backup. Two notes on that: first, it's a pet peeve, but back up should be two words when used as a verb (a backup is a noun), and buttons should always read as actions; second, I think emphasizing the do it now nature of the button is useful here, especially since backups should be made automatically, periodically. In fact, changing the description to convey this would also be useful. • It would also be great to have an indication of the last time a backup was made, to know whether or not it's worth invoking another. I would add a Last backup: label with a relative date (eg. 3 hours ago) to the backup column. • The restore column would do well to convey the results of the action. Specifically, that it will restore the Journal to a previous state, which could result in data loss. • It's not clear from the image what happens when either of these actions are invoked. I'd recommend immediately disabling the other column (eg. disable the restore button when a backup is initiated), and replacing the button clicked with an inline progress bar (determinate, if at all possible; perhaps indeterminate during initialization) so there's adequate feedback. • If there is any way to detect when a Journal has been corrupted/wiped, it would be great to have the empty Journal screen be replaced by a prompt to recover from backup, if one is known to exist. This would make it much easier for kids to recover the Journal as it was in such circumstances. Eben PS. I think its useful to consider the UI for Apple's Time Machine here, since it has a number of similarities. On Thu, Apr 8, 2010 at 11:05 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On Thu, Apr 1, 2010 at 04:30, Bernie Innocenti ber...@codewiz.org wrote: On Thu, 2010-04-01 at 09:21 +1100, James Cameron wrote: On Wed, Mar 31, 2010 at 06:36:06PM -0300, mabente wrote: So, what do you guys think? I like it. I presume it won't appear unless a school server is known? I wonder if this can be done at the control panel level... probably easier to let the icon appear anyway, and then disable the functionality in the window. In the future, we may want to add a backup/restore function for removable storage. Any comments from the design team? Regards, Tomeu -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Keep confusion, yet again
On Wed, Apr 21, 2010 at 6:22 PM, Bert Freudenberg b...@freudenbergs.de wrote: On 21.04.2010, at 23:57, Chris Ball wrote: Hi, I think that's what we want; this new string will come up as untranslated in pootle, alerting translators to submit translations for the clearer string. Ah, that's fine. (I assumed we'd want to use the old translations in the meantime.) - Chris. The actual problem is that renaming the button does not help. The mouse-over balloon in Etoys says: Keep a copy of the current project in the Journal It's no use. There are only two options IMHO: 1) Remove the button. If you want to copy an entry, use the Journal. 2) Make the button actually overwrite the entry. No silent auto-save on exit, but ask if save is desired. I'd lean toward the first option. It's intended purpose was always to be a convenience on top of auto-save, that simply forced a new version. Once Sugar has full version support, and a Journal updated to take advantage of it, restoring the Keep functionality as it exists probably wouldn't cause problems anymore. Until then, I think the auto-save is much friendlier than the usual prompt-on-quit, with the possibility for lost work. Eben - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Keep confusion, yet again
On Wed, Apr 21, 2010 at 7:18 PM, Chris Ball c...@laptop.org wrote: Hi Eben, I'd lean toward the first option. It's intended purpose was always to be a convenience on top of auto-save, that simply forced a new version. Once Sugar has full version support, and a Journal updated to take advantage of it, restoring the Keep functionality as it exists probably wouldn't cause problems anymore. Until then, I think the auto-save is much friendlier than the usual prompt-on-quit, with the possibility for lost work. Think I'm having trouble following -- are you proposing that we remove the Keep button now, and also remove the prompt-on-quit dialog now? No, sorry. The current prompt-on-quit is fine, as it only occurs when you stop a brand new activity instance. It basically asks do you want me to keep track of this thing in your Journal, and from then on it will auto-save as usual. Since the Keep button is causing so much confusion, I was proposing to remove it for now (until we have more complete version support), but keep the prompt the first time a new instance is stopped. We can still skip the prompt if the instance is manually renamed, under the assumption that naming the item implies a desire to track it in the Journal. Eben Thanks, - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Show file size in Journal
On Thu, Apr 8, 2010 at 7:18 AM, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: On Wed, Apr 07, 2010 at 08:43:29PM -0300, Kenny Meyer wrote: Bernie and I have been discussing about showing the file size in Journal view of Sugar 0.84.x, [...] As already mentioned on the ticket, Sugar 0.86+ does that (in the details view). The commits are 85b833 [1] and 6c3fd034 [2]. A quick look suggest they should be easy enough to backport. Yeah, that's certainly one place it makes sense to show it; the palette for Journal objects also makes sense. I like the idea of exposing it as blocks, and agree with Bert that its essential that those blocks be linear. With that approach, maybe the details view is the only place that there is room to illustrate size that way. One approach to showing size might be to pretend that we're in base 9, so that one big block is 1MB, and 9 small blocks stack together in a 3x3 grid to form a big block. I'm not sure granularity needs to be more precise than that (though we could also show a precise value as a number, too). Now, I thought of an extra column Size, showing the size of the file in bytes. I don't think taking away space from other columns is a good idea on the XO. Agreed. Reclaiming space sounds like a good use case for a separate activity that shows the data store in a view optimized for this particular task. Long ago, we anticipated that the Journal would, at some point when space reached a critically low point, assist children in cleaning up their Journals. The plan was to create some heuristic for identifying entries in the Journal that may not be that useful, and/or would be most beneficial to remove. For instance, with versioning, it might be safe to remove old and/or intermediate versions that were auto-saved; it might be safe to remove really old entries that aren't starred; entries that haven't been opened in a while; entries that are extra large; etc. Entries that fit several of these conditions might be the first recommended. Anyway, in cleanup mode, we could present a list which did highlight size as a key element. Basically, take your suggestion of making a separate activity, and just wrap it into a separate mode of the Journal instead. Whether or not this mode was always entered automatically, or also had a manual trigger, would need to be decided. Perhaps instead of representing the total number of blocks the Journal takes up, this mode could instead represent the number of blocks needed to be cleared to continue using their Journal normally. Then kids could compare the blocks of various entries against the remaining number in their goal meter to make decisions about what to remove. Eben [1] http://git.sugarlabs.org/projects/sugar/repos/mainline/commits/85b833960ded9148fbb42e773720ba3bcb02145e [2] http://git.sugarlabs.org/projects/sugar-toolkit/repos/mainline/commits/6c3fd0346c1876ad501c3c91d50cdf42f7e0a9dc CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJLvbtrAAoJELpz82VMF3Da7/kH/R6IMUCJi9QUEgSFGrj88EmO /OhArTf2vHaeiovI4Ew06xDdQLZbtLoX3+0AdXHyuMvKg+aR93F7BdGkXozB4QBY Dm3P6yOCI25yIKjolAOEoLpujDiHPOCldqEjqMnvmshv3IlgaB1dIM/KHQa0OY43 I5qZYz6xxZ8fUPv238y+11qiId1VedWLHPiQVb0xHRJAELDRtiXv+D325zOrM8cm qY34Rq+NNF0bPDxHVCmDJ2J/QQvk40U5JD0qoxyNhWy77XVpWJHJwrSJxVqZGVAQ UvKojBYCxipDAsNwfPTeXX7NsSuS3/0TORpnLk/2HcZkYD/VbiOksLR//Q0eH/4= =RBBS -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Show file size in Journal
On Thu, Apr 8, 2010 at 8:35 AM, Bert Freudenberg b...@freudenbergs.de wrote: On 08.04.2010, at 13:47, Eben Eliason wrote: On Thu, Apr 8, 2010 at 7:18 AM, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: On Wed, Apr 07, 2010 at 08:43:29PM -0300, Kenny Meyer wrote: Bernie and I have been discussing about showing the file size in Journal view of Sugar 0.84.x, [...] As already mentioned on the ticket, Sugar 0.86+ does that (in the details view). The commits are 85b833 [1] and 6c3fd034 [2]. A quick look suggest they should be easy enough to backport. Yeah, that's certainly one place it makes sense to show it; the palette for Journal objects also makes sense. I like the idea of exposing it as blocks, and agree with Bert that its essential that those blocks be linear. With that approach, maybe the details view is the only place that there is room to illustrate size that way. In the details view you only see a single entry, I'd expect the exact size shown numerically there. The graphical form is much more useful for visually comparing multiple entries. One approach to showing size might be to pretend that we're in base 9, so that one big block is 1MB, and 9 small blocks stack together in a 3x3 grid to form a big block. I'm not sure granularity needs to be more precise than that (though we could also show a precise value as a number, too). Just to be pedantic: that would still be linear, not base-9 logarithmic ;) Yeah. Otherwise the idea is sound, at least for entries up to a few MB. But what about larger ones? Given that Sugar runs on netbooks that frequently have a 160 GB disk, there should be some theory about dealing with large files IMHO. Well, for arguments sake, we could assume that 1 unit (about 114 bytes) is 5px square. So 1MB (9 units) would be, say, 5*3 + 2 (for spacing) = 17px square, and therefore up to 9MB is representable within 17*3 + 4 (again, for spacing) = 55px square. That's exactly the maximum area of an icon within one grid cell. Maybe that's too small, but maybe not. The real problem is that linear (which we both want) is fundamentally non-scalable in a fixed screen size. Without a logarithmic scale for size, we'd need to have a zooming factor to continue to fit more blocks into fewer pixels. Perhaps we could drop down to 3px squares for the smallest unit after some critical point. Or, we could try using colors/values to convey the difference in block sizes. Unfortunately, it's a bit harder to educate that 9 blue blocks equals one red block than that 9 small blocks equals one large block. Eben - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] scalability in the neighborhood view
On Wed, Mar 24, 2010 at 2:38 PM, Frederick Grose fgr...@gmail.com wrote: On Wed, Mar 24, 2010 at 8:57 AM, Eben Eliason eben.elia...@gmail.com wrote: ... Yeah, definitely. We did a lot of thinking on this topic way back when, so there is some documentation already describing a proposed model: http://wiki.sugarlabs.org/go/Design_Team/Specifications/Groups We also have a first series of mockups of how this might look in the UI, though I'm not sure that those are posted anywhere, ... See http://wiki.sugarlabs.org/go/Design_Team/Proposals/Groups Yup, those are the ones! Thanks. Eben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] scalability in the neighborhood view
On Wed, Mar 24, 2010 at 8:32 AM, Martin Langhoff martin.langh...@gmail.com wrote: On Wed, Mar 24, 2010 at 3:28 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: Yep - no prob for me. The GUI side probably needs a bit of extra thinking so that it avoids being specific to the backend works (moodle in this case)... I was thinking that Moodle would put contacts in groups in the server side and Sugar would just use the standard Telepathy interfaces. Yep. Agreed, same here. What I was thinking about was the UI design... for example, just one very obvious case we have to deal with: it is a good idea to design the UI so that we have a metaphor to edit groups (create, add/remove users). This can work server-less or with XMPP/Moodle backends -- we have to define a lowest common denominator and aim to use just that. Yeah, definitely. We did a lot of thinking on this topic way back when, so there is some documentation already describing a proposed model: http://wiki.sugarlabs.org/go/Design_Team/Specifications/Groups We also have a first series of mockups of how this might look in the UI, though I'm not sure that those are posted anywhere, and they might need some tweaking in any case. Agreeing on the behavior is key, though. For the initial implementation we are discussing, I would avoid implementing the client-side editing, and go instead for something easy: just read the groups via Telepathy - Gabble - XMPP (which in turn is controlled by Moodle). But if we have a plan for the full interaction, we can start implementing the basics. Agreed. We can start by basically just adding the filter to the UI for now, and add any creation/management UI in the future. Without looking at the long term UI, maybe we implement something and then... have to change the UI significantly in the next stage. Yeah, I think that's a great goal; I also think it will be relatively easy to succeed in doing so, especially if the only core UI added for now is the group filter (in the Groups view, in the Journal, for various actions eg. Share with, Send to, etc.) It's not a big deal... I just think it would be good to have a chat or two to define some of those lowest common denominators strategies, and some key features. I look forward to hearing feedback on that draft spec in the wiki. I just read through it again, and from my perspective it still sounds pretty solid. I know little of moodle, so I'd be curious to know how well it integrates there, but it seems like a fairly basic set of parameters and actions that will still provide a great deal of versatility. An example on the 'feature' side: one of the strongest requests from the field I have is something I don't think we ever thought about -- teachers want to set a mode in Moodle that forces all kids' XOs to only show _this_ group/course/classroom members. Not sure how that'd work but I get that request from several independent deployments. Would you like to add a section to the wiki page entitled something like Other Requested Features to track any specific details like this that the current proposal doesn't cover? I probably need to think these ideas through, and throw them in the collective pot... if you're interested... Definitely. Eben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] scalability in the neighborhood view
On Wed, Mar 3, 2010 at 2:08 PM, Martin Langhoff martin.langh...@gmail.com wrote: On Wed, Mar 3, 2010 at 1:02 PM, Caroline Meeks solutiongr...@gmail.com wrote: would be a nice feature to eventually have to let the teacher narrow down the neighborhood based on a specific Moodle group, for a specific period of time. That is have students focus on only other students in their class right now. Yeah, I've thought of that, and heard/read this kind of request a few times. Once we are where Tomeu wants to take us, I think it'll make sense to add something like what you describe, perhaps in the neighbourhood view or in the 'friends' view. This has always been the intent of the middle view, which was designed as a Groups view (with a number of configurable filters for various groups a student might be a part of) and is currently just a Friends view. After adding further group support, I suspect Friends will just be one of the available groups. I know that improvements to Groups/Friends view have been no the table for upcoming releases, so maybe we can start with a Moodle-only approach and later extend to a generic system that works with or without a server. Eben It's probably a mode that Moodle signals to the laptops. The data on the Sugar side is the same, but the UI changes a bit to help focus. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Showing 3G Connection Errors
On Sat, Feb 27, 2010 at 10:07 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On Fri, Feb 26, 2010 at 23:03, Gary C Martin g...@garycmartin.com wrote: On 26 Feb 2010, at 15:59, Tomeu Vizoso wrote: On Fri, Feb 26, 2010 at 13:30, Daniel Castelo dcast...@plan.ceibal.edu.uy wrote: I've applied Eben's mockup, I also tried to show the connection errors using an alert inside the palette. This solution has the problem that Tomeu said: when user clicks connect, the palette is hidden and users could miss the notification. Is a solution that doesn't look nice, because the palette should resize to show the errors. We could bring attention to the issue by using a notification, but I'm not really seeing a good solution for this. Any ideas? Is it possible to override the dismissing of the palette when connect is clicked? User sees a 'connecting' positive feedback message in the palette, with the palette only auto-dismissing after a successful connection? I think it's pretty doable from the coding side and could work quite well in this case. About the design side, do we want to introduce this variation? This could be a bit odd. Since the palette is attached to the Frame, does that also prevent the Frame from hiding? How long does it usually take to connect? Could it get in the way of the user? I think in an upcoming release it makes sense to put more time into the notification system to support this type of thing. (For instance, upon failure, the 3G icon would appear and blink in the lower right corner for a bit; It would continue to have a different visual treatment within the Frame if you didn't click it in time in the corner; When clicked it would reveal the error and any actions to take.) In the short term, I guess we could still use the notification system to get your attention, though the rest of the behavior wouldn't be as clean. But, if we're using the usual transformation of the icon from white to XO colors when connecting, and drop back to white when connection fails, we're no worse off than wifi connection errors until we institute a more complete design for notifications. Eben Regards, Tomeu Regards, --Gary Thanks, Tomeu On Sun, Feb 21, 2010 at 12:27 PM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On Fri, Feb 19, 2010 at 16:41, Eben Eliason eben.elia...@gmail.com wrote: On Wed, Feb 17, 2010 at 2:27 PM, Daniel Castelo dcast...@plan.ceibal.edu.uy wrote: Hi, today we don't show all the 3G connection errors. The unique error that we show is the Authentication Error when the Pin/Puk Sim configuration is wrong. In this case we show the error in the connection pallete. When users clicks over the message, the pallete returns to normal behavior. We want to display all the connection errors. How is the best way to show this? I'd recommend showing one or more buttons for dismissing the error and taking any other relevant actions within the palette. Clicking on the text label likely won't be very discoverable. For instance, this error might have two normal buttons for Cancel and Show Settings (assuming something in settings can be adjusted to improve the situation; I don't know enough about what this error means). Hmm, but if the error appears in the palette, and the palette is hidden when the Connect option is clicked, won't most users miss the notification? Regards, Tomeu Eben -- Ing. Daniel Castelo Plan Ceibal - Área Técnica Avda. Italia 6201 Montevideo - Uruguay. Tel.: 601.57.73 Interno 2228 E-mail : dcast...@plan.ceibal.edu.uy ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Ing. Daniel Castelo Plan Ceibal - Área Técnica Avda. Italia 6201 Montevideo - Uruguay. Tel.: 601.57.73 Interno 2228 E-mail : dcast...@plan.ceibal.edu.uy ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] 0.88 Meeting --- 20. Feb 2010 (15:30 UTC)
I,too, will be unavailable. I'm out of town for the weekend so don't try to schedule around me, but I look forward to reviewing the meeting notes and/or summary of findings. Eben On Fri, Feb 19, 2010 at 10:12 AM, Christian Marc Schmidt christianm...@gmail.com wrote: Hi Simon--unfortunately I won't be able to make it this Saturday, but I really would like to hear the outcome of the tests. Could we move the meeting to later that day, say around 2pm EST? Christian On Thu, Feb 18, 2010 at 3:12 AM, Simon Schampijer si...@schampijer.de wrote: Sorry, of course the meeting is the 20th of February. Regards, Simon On 02/18/2010 09:11 AM, Simon Schampijer wrote: Hi, this Saturday we will have our bi-weekly design meeting. We will chat about the outcome of the testing of the Start new vs Resume behavior. As a second item I would like to discuss the questions raised regarding the 3G Feature by Daniel [1]. Daniel, if you have time on Saturday, it would be great if you could attend. Thanks, Simon Channel: #sugar-meeting (irc.frenode) Time: 15:30 UTC [1] http://lists.sugarlabs.org/archive/sugar-devel/2010-February/022541.html -- anyth...@christianmarcschmidt.com 917/ 575 0013 http://www.christianmarcschmidt.com http://www.linkedin.com/in/christianmarcschmidt http://twitter.com/cms_ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Showing 3G Connection Errors
On Wed, Feb 17, 2010 at 2:27 PM, Daniel Castelo dcast...@plan.ceibal.edu.uy wrote: Hi, today we don't show all the 3G connection errors. The unique error that we show is the Authentication Error when the Pin/Puk Sim configuration is wrong. In this case we show the error in the connection pallete. When users clicks over the message, the pallete returns to normal behavior. We want to display all the connection errors. How is the best way to show this? I'd recommend showing one or more buttons for dismissing the error and taking any other relevant actions within the palette. Clicking on the text label likely won't be very discoverable. For instance, this error might have two normal buttons for Cancel and Show Settings (assuming something in settings can be adjusted to improve the situation; I don't know enough about what this error means). Eben -- Ing. Daniel Castelo Plan Ceibal - Área Técnica Avda. Italia 6201 Montevideo - Uruguay. Tel.: 601.57.73 Interno 2228 E-mail : dcast...@plan.ceibal.edu.uy ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Feature] [DESIGN] Enhanced Color Selector
On Wed, Feb 3, 2010 at 5:06 PM, Simon Schampijer si...@schampijer.de wrote: Thanks Tim for your feedback, On 02/02/2010 11:54 PM, Tim McNamara wrote: On 2 February 2010 22:45, Simon Schampijersi...@schampijer.de wrote: In the design meeting and the ml-thread the '+' layout and the rows of XOs were favored. Eben brought as well the 'static rows with separated fill/stroke' on the table. Let's try to find an agreement. The proposal looks great. May I suggest a revision to the string literals? Click to change stroke color: = Outline Click to change fill color: = Body These sound good to me. Stroke/Fill are terms of art in vector drawing area. My guess is that the terms outline and body (when looking at the XO figure) may be more natural. I guess this is right, stroke/fill are technical terms. Maybe Inline/Outline would work, too? I feel we can omit Click to change or replace it with Choose. I'm pretty sure it'll be obvious by exploration that clicking on the little XOs changes the big one. Choose sounds good to me, too. We may not even need the instruction at all. I think just using Body: and Outline: labels could suffice. Good suggestions, Eben Thanks, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN][FEATURE] 3G modem support
Here is a mockup of the panel with a proposed icon and a few visual tweaks, as promised. Sorry it took a week to find the time. I'm happy to export any of the icons shown as needed, once a design is agreed upon. Eben On Sat, Jan 16, 2010 at 3:07 PM, Eben Eliason eben.elia...@gmail.com wrote: On Sat, Jan 16, 2010 at 2:47 PM, Simon Schampijer si...@schampijer.de wrote: On 01/15/2010 02:36 PM, Daniel Castelo wrote: On Fri, Jan 15, 2010 at 5:48 AM, Simon Schampijersi...@schampijer.dewrote: On 12/11/2009 08:36 PM, mabe...@paraguayeduca.org wrote: It has been discussed before and i have been working on it with Daniel Castelo from Uruguay. This is the link of the formal proposal, I will be updating it soon. http://wiki.sugarlabs.org/go/Features/3G_Support Hi Martin Daniel, thanks for proposing and working on this Feature! Your Feature has been accepted for the 0.88 release cycle. It has a clear value for many Sugar users and the need has been expressed from people from the field. It is, what I am especially happy about, implemented by locals! From a technical point of view the changes are not too invasive. * Design (from the Feature Page)* An icon will be added to the frame when a modem is connected, and the user will be able to connect and disconnect from there. Also, a section will be added to the control panel that will allow entering the details needed by the connection. We will have a design meeting this weekend [1]. Do you have any particular questions regarding the UI for your Feature? Do you have an icon for the frame device and the control panel already? Great!! No, we don't have any icon. Concerning the 0.88 release: The most important date is the Feature Freeze Feb 01. The Feature must have been reviewed by the module maintainer (in your case Tomeu for Sugar) and pushed to the repository. I know that you are in contact with Tomeu already and patches are in review. Furthermore please keep your Feature page up to date (testing plan, release notes). Ok. Thanks. Thanks, for working on the page. Here is the feedback from the design meeting: the UI design looks good, a few minor suggestions: ===Device Icon=== - the disconnect option in the device icon palette should use an icon just like other network devices. - the connection time should be shown in the primary palette, eg. connected for 02:22 instead - data sent: make that: [UP] 23kb [DOWN] 31 kb I'll include a mockup of this palette along with the icon. My thought was that [UP] and [DOWN] above would actually be icons. Eben ===Control Panel=== - left align the options ===Icon=== Eben will follow up with an icon. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel attachment: 3G_device.png___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN][FEATURE] 3G modem support
On Sat, Jan 16, 2010 at 2:47 PM, Simon Schampijer si...@schampijer.de wrote: On 01/15/2010 02:36 PM, Daniel Castelo wrote: On Fri, Jan 15, 2010 at 5:48 AM, Simon Schampijersi...@schampijer.dewrote: On 12/11/2009 08:36 PM, mabe...@paraguayeduca.org wrote: It has been discussed before and i have been working on it with Daniel Castelo from Uruguay. This is the link of the formal proposal, I will be updating it soon. http://wiki.sugarlabs.org/go/Features/3G_Support Hi Martin Daniel, thanks for proposing and working on this Feature! Your Feature has been accepted for the 0.88 release cycle. It has a clear value for many Sugar users and the need has been expressed from people from the field. It is, what I am especially happy about, implemented by locals! From a technical point of view the changes are not too invasive. * Design (from the Feature Page)* An icon will be added to the frame when a modem is connected, and the user will be able to connect and disconnect from there. Also, a section will be added to the control panel that will allow entering the details needed by the connection. We will have a design meeting this weekend [1]. Do you have any particular questions regarding the UI for your Feature? Do you have an icon for the frame device and the control panel already? Great!! No, we don't have any icon. Concerning the 0.88 release: The most important date is the Feature Freeze Feb 01. The Feature must have been reviewed by the module maintainer (in your case Tomeu for Sugar) and pushed to the repository. I know that you are in contact with Tomeu already and patches are in review. Furthermore please keep your Feature page up to date (testing plan, release notes). Ok. Thanks. Thanks, for working on the page. Here is the feedback from the design meeting: the UI design looks good, a few minor suggestions: ===Device Icon=== - the disconnect option in the device icon palette should use an icon just like other network devices. - the connection time should be shown in the primary palette, eg. connected for 02:22 instead - data sent: make that: [UP] 23kb [DOWN] 31 kb I'll include a mockup of this palette along with the icon. My thought was that [UP] and [DOWN] above would actually be icons. Eben ===Control Panel=== - left align the options ===Icon=== Eben will follow up with an icon. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] 'Resume' vs 'Start a new' Activity
On Wed, Jan 13, 2010 at 8:32 AM, Walter Bender walter.ben...@gmail.com wrote: On Wed, Jan 13, 2010 at 8:15 AM, Gary C Martin g...@garycmartin.com wrote: On 11 Jan 2010, at 20:44, Walter Bender wrote: On Mon, Jan 11, 2010 at 3:32 PM, Simon Schampijer si...@schampijer.de wrote: On 01/11/2010 06:12 PM, Wade Brainerd wrote: My feeling regarding all this is that the problem is deeper than finding a way to Resume Latest or Start New from the home screen. IMO, the whole idea of Resume Latest is broken and needs to be ditched. The Journal is the place to resume activities. We need to make the Journal more discoverable and usable instead of trying to mash its features into the home screen. My findings are as well that the Journal is the natural place to resume an activity. The home view is the natural way to create a new activity, since it contains a graphical representation with the available activities. I think resuming is a secondary option we can provide, but should not be the default option when you click on the icon. To overcome the issue of constantly creating new activities I liked the 'open the full palette on left click' option. The learner is then provided with options to choose from. I like this too. It is worth mentioning that on non-OLPC-XO hardware, there is no easily discovered (or typed) dedicated key or mouse movement to get you to the Journal--one of the reasons we have also discussed having the Journal icon always available in the Home View (I am in favor of always at the bottom of the circle). All of these changes collectively may help. I've been trying to stay out of this discussion so far, watching for what might stick. So summing up so far: - Always show Journal in the home ring, though I'd favour having it as the first item, so that would make it always at the top of the circle ;-) - Home view reverted back to the 'start new' activity focus, all icons are un-coloured. - Single left click always reveals the palette with the 'start new' item at the top and 'resume' items below. Some minus design points here as 'start new' and 'resume' will both become 2 clicks away, and take extra palette cursoring dexterity to reach. You could argue both 'start new' and 'resume' will drop to second level features with 'activity palette information' becoming the top level home feature. Being able to read (some of) this palette text would also now be required, so our 'low floor' just got a little higher :-( I do agree though that this provides a compromise between reducing Journal spam and preventing the unintentional overwrite of existing Journal work by making the choice explicit. I am with you until here. I think we need to be very careful with the introduction of such additional complexity in the UI. Even for older kids, those using the OLPC-XO-1 laptops that have the old jumpy touchpad will have a hard time with this. I would urge the design team to explore a few more ways to solve this problem spatially rather than temporally. One potential design I kind of liked (though I do recall others did not, for various reasons) was to represent only new activities in the ring, retaining the one-click instantiation and the palette as it exists, and add a new yet separate feature to the view. This would place the Journal icon persistently at (say) the bottom left corner of Home, and then to the right of it, separated by a thin rule, a row of the (say) 10 most recent activity instances. This line could contain multiple instances of the same activity (eg. 3 different Write instances), and would maintain their temporal relationship as they march across the screen and into the persistent Journal icon. This makes the Journal persistent, and logically separates the notion of creating something from scratch and resuming a previous activity. This is one of a number of potential alternatives, I think. I do also share the sentiment that the Journal is the logical place to emphasize for resuming, and that perhaps the first order of business is to make sure that it's as accessible as possible. If every lesson begins with go to the Journal and resume the story we were working on yesterday or go to the home view to create a brand new drawing (and the UI affordances make these equally easy to accomplish) we might not need to conflate home view with both possibilities. Eben regards. -walter Regards, --Gary -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] [DESIGN] Frame Panels
On Sun, Dec 13, 2009 at 12:42 AM, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, At the end Journal Plugins mutated to Frame Panles feature. All UI visible changes I wanted to implement in plugins could be done via Frame Panle components(the rest of code are shell agnostic). Frame Panles feature has the same major idea, social context - giving non core developers more freedom in case of releasing/supporting theirs code, e.g. adding GSM modem support could be implemented not in core(thus stuck to sugar version, when previous sugar version users can't grab last changes of GSM modem component) but as a standalone activity(and deployed as a regular activity). Is this an extension of the device concept already present? The idea there was to allow anyone to create devices (in the bottom edge of the frame) that added extended features (such as text-to-speech, additional hardware support, dictionaries, etc.). Having a way to separate these from the core of Sugar, and even add or remove them at will, would be nice. == Summary == Treat frame as a containers(upper, left, right and bottom) for predefined or custom components i.e. having GNOME panels analog in sugar. I'm a bit confused by this. The panels, clockwise from top, are for activities, people, devices, and objects (clipboard). Only the bottom edge is currently thought of as a place for extension. Are you proposing that all of these would be extensible? == Detailed Description == The major reason is to let activities like FileShare or Chat special UI representation in shell's interface. It could be also useful if user wants fast access to some activities like Journal replacements. I would raise some caution here. The Frame was specifically designed as a place for active elements to live, and is specifically not a launcher. As such, any running activities, current friends, available devices, etc. appear there. Your description of fast access makes it sound more like a launcher and less like a place of status. Any of four panels could be stuck i.e. let user see its components all time. This is an interesting idea. We played with similar concepts early on, but decided at the time that the Frame as more comprehensible as a single unit that could be shown and hidden at will. If we break that paradigm, how do we handle the overlap that a persistent frame edge would cause? Does the activity window move/shrink in these instances? === Predefined components === * rings switch * activities list These are views within the Home zoom level. What's your proposal for making these Frame components? * clipboard * users list Yup, these are the left and right edges, currently. * sources list * network component Are these equivalent to the devices (bottom) edge of the frame? Are you proposing we split them somehow? * notification area I'd much rather see a general notification system built up (we have the beginnings of one already). There are a number of design mockups showing how notifications are bound to the 4 corners of the screen, associated with the 4 edges for activities, people, devices, and objects. notifications would include activity invitations, group invitations, people joining/leaving activities, low battery, lost network, etc. I think these various notifications belong in the context of the respective edges of the frame, instead of in a single area. Overall, there are 7 components you've identified here, so it's unclear to me how these map onto the 4 edges of the Frame. == Benefit to Sugar == * let users more freedom to organize sugar shell how they want * provide to activity developers a way to integrate theirs activities * to shell UI(useful for activities that work in background and * requires some kind all-time-present indicator in UI) * having stable API for panel components, activity developers have more * freedom and aren't stuck to core releases e.g. Network * activity/component(analog of NM widget in GNOME) could support * several sugar releases and previous release sugar users will benefit * from last Network component. * previous sugar release users will benefit from last updates of * predefined components as well == UI Design == * all of four frame panels could be stuck * manage components, way to add-new/remove/move components This part definitely sounds like a good idea, to me. * components could have shell level key shortcuts This also sounds good, but we'll have to be quite careful about it to avoid breaking activities. Eben == User Experience == * sugar frame as a regular GNOME panels -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Scrollbar width
On Fri, Dec 11, 2009 at 3:02 AM, Albert Cahalan acaha...@gmail.com wrote: It's perfectly reasonable to have a scroll bar that isn't anywhere near the edge of the screen. (scrolling a list, etc.) We must not forget this when discussing things like infinite target width. Of course. My point here is simply that many activities have one large scrolling content region (or, at least, one primary one); In cases where the scrollbar is conceptually at the edge of the screen, we should be sure that it is also technically at the edge of the screen. In a sense this consideration is orthogonal to the issue of scrollbar width, in that it should be ensured regardless since it has huge usability benefits in many likely scenarios (though, as you point out, certainly not all). That said, at least for the common case of the scrollbar being at the edge of the screen and possibly elsewhere, there is a solution. Scrollbars could widen up as the mouse goes over them, overlapping into/above the area that is to be scrolled. It's a nice solution, allowing for scrollbars 100 pixels wide. This is an interesting thought, but it seems to me that it's actually a solution proposed for the wrong circumstance. The scrollbars that lie at the edge of the screen are the ones that needn't be large, since grabbing them (assuming they are properly edge-aligned) is easy regardless of their width. It's those that float within the UI, such as a scrolling left column (eg. Pippy examples) that are hardest to target, and which need adequate affordances to make them usable. Increasing the target area dynamically on hover is definitely a solution worth experimenting with. Speed is critical of course. Being slow like the Frame would be some kind of torture. My best guess for appropriate timing: I'm not even sure an animation would be critical to understanding this model. One possibility might be to only increase the size of the scroll handle (leaving the bar itself thin), when the cursor is within range of it. It could grow from its center, so that it hovers above yet centered on the bar it belongs to, perhaps settling on a width 3x that of the bar. Eben a. movement begins in less than 30 ms b. movement is done in less than 200 ms (no exceptions ever) In that time there ought to be 6 to 12 frames drawn. Drop frames as required to meet the required performance. I'm thinking the speed ought to vary, like this: 0 ms, 8 pixels (begin state) 20 ms, 12 pixels 40 ms, 16 pixels 60 ms, 24 pixels 80 ms, 40 pixels 100 ms, 72 pixels 120 ms, 88 pixels 140 ms, 96 pixels 160 ms, 100 pixels (end state) Motion blur would help. (precomputed I suppose) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Feature] activity.info enhancements
On Fri, Dec 11, 2009 at 2:26 PM, Tomeu Vizoso to...@sugarlabs.org wrote: On Fri, Dec 11, 2009 at 17:18, Sayamindu Dasgupta sayami...@gmail.com wrote: On Fri, Dec 11, 2009 at 11:13 PM, Walter Bender walter.ben...@gmail.com wrote: Summary: It would facilitate the packaging of Sugar activities into RPMs and DEBs if there were additional information available in the activity.info file. Details: In walking the process of creating an RPM of one of my activities with Sebastian Dziallas, who is doing lots of packaging for Fedora and SoaS, we observed that many fields in packages' .spec files could readily be pulled from the activity.info file. A few additional fields would be necessary, such as the following: * a short summary * an URL to the source package * an URL to the activity home page * the required dependencies to run None of these additional fields are particularly onerous for an activity developer to provide and it would enable the creation of a script (as part of setup.py/bundlebuilder.py) to do most of the work in creating the .spec file. (I assume .deb has similar requirements to .rpm). Things are more complex for activities that include binaries and the like, but for the most part, we should be able to greatly facilitate upstream maintenance of our code while asking little more of Sugar developers. None of these additional fields need be required, but their inclusion would make things easier. (This is not a new idea, but one that seems timely given all the upstream interest in Sugar these days.) It may be interesting to factor in localization (eg: translation of the description, etc) into this discussion. We already translate parts of activity.info so it may be trivial to extend the mechanism. However, it does increase the workload on translators a bit, and we need to agree on which fields to translate (for example, if we have a non-UI-visible field called category or tags, it may not make sense to translate it). I was thinking of displaying these tags in the activity list (or it's already happening, not sure). Also, if we allow searching for those, we would need to do so with the ones in the local language. I think displaying them in the list might just add visual noise, but their primary intent is to allow searching, and as you point out, it's critical to have good translations for that to work. Eben Regards, Tomeu It may also be worthwhile to keep some kind of compatibility with the desktop-entry spec http://standards.freedesktop.org/desktop-entry-spec/latest/, in case we add support for standalone activities in the future. Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Scrollbar width
On Thu, Dec 10, 2009 at 7:54 AM, Paul Fox p...@laptop.org wrote: benjamin wrote: Hello, On Wed, 2009-12-09 at 22:43 -0500, Art Hunkins wrote: I've now got whole-screen scrollbars working well in my music activities, but I'd like to make the bars wider. The automatic settings (as used in most activities) are too narrow for my taste. First of all I would like to say: Please do not play with themes, just because you don't like something that much ... (especially should you dislike them in general and not only in your activity) Other than that. IIRC the reason for the scrollbars to be that narrow was the plan to use the Grab-Key+Touchpad for scrolling. This means that the main purpose of the scorllbar is to show the position, but not to use the handle itself for scrolling. and just in case it's not clear from the above -- the grab-key+touchpad feature is present in XO-1.5 releases, and available for the XO-1 if the olpc-kbdshim package is installed. I was a proponent for grab scrolling in the early days of Sugar at OLPC. However, it seems clear now that, without customized hardware (which was the assumption back then) this solution simply isn't viable as an intuitive and discoverable way to navigate content. I think that retaining the functionality via some other mapping or shortcut would be nice (especially to offer the functionality as designed on the XO hardware itself), but I don't see reason not to improve the usability of Sugar on all platforms by increasing the scrollbars to a more manageable width. Of course, in addition to this we should make sure that wherever possible the scrollbars are given every last pixel up to the edge of the screen, so that they become, effectively infinite in width (or height, when horizontal), thus making them difficult to miss. Eben paul =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Scrollbar width
On Thu, Dec 10, 2009 at 12:30 PM, Sean DALY sdaly...@gmail.com wrote: FWIW, I have seen lots of kids ages 6-8 who know what a scrollbar is, but have a hard time mousing it up and down when using SoaS, even on a larger screen such as the Dell Latitude 2100 education netbook. This, incidentally, is precisely the reason the grab key was designed. Scrolling in this manner requires continuous pressure on the mouse button, while simultaneously moving the finger across the trackpad, which can be difficult, especially on smaller laptops, and for smaller/younger fingers with less developed motor skills. The grab button (there, quite crucially, are two of these on the XO: one on each side of the spacebar) was designed to allow children to use their non-dominant hand to press the button while using their other hand on the trackpad to manipulate the view. This design was meant both to eliminate the need to target the scrollbar in the first place (since this would work anywhere within the scrolling region, just like 2-fingered scrolling), and to make it easier for children to do since drag'n'drop can be tricky. Eben Sean On Thu, Dec 10, 2009 at 6:13 PM, Gary C Martin g...@garycmartin.com wrote: On 10 Dec 2009, at 14:58, Eben Eliason wrote: On Thu, Dec 10, 2009 at 7:54 AM, Paul Fox p...@laptop.org wrote: benjamin wrote: Hello, On Wed, 2009-12-09 at 22:43 -0500, Art Hunkins wrote: I've now got whole-screen scrollbars working well in my music activities, but I'd like to make the bars wider. The automatic settings (as used in most activities) are too narrow for my taste. First of all I would like to say: Please do not play with themes, just because you don't like something that much ... (especially should you dislike them in general and not only in your activity) Other than that. IIRC the reason for the scrollbars to be that narrow was the plan to use the Grab-Key+Touchpad for scrolling. This means that the main purpose of the scorllbar is to show the position, but not to use the handle itself for scrolling. and just in case it's not clear from the above -- the grab-key+touchpad feature is present in XO-1.5 releases, and available for the XO-1 if the olpc-kbdshim package is installed. I was a proponent for grab scrolling in the early days of Sugar at OLPC. However, it seems clear now that, without customized hardware (which was the assumption back then) this solution simply isn't viable as an intuitive and discoverable way to navigate content. I think that retaining the functionality via some other mapping or shortcut would be nice (especially to offer the functionality as designed on the XO hardware itself), but I don't see reason not to improve the usability of Sugar on all platforms by increasing the scrollbars to a more manageable width. I'd argue the narrow scrollbar width is still a relevant design choice, being there to indicate document length and current view location into it. Most non-XO hardware platforms are very likely to have their own hardware support for a scroll wheel type behaviour. I very rarely need to drag a scrollbar these days, it's all two fingered scrolling which works fine in Sugar on a VM (though we could do with a control panel to adjust sensitivity). Regards, --Gary Of course, in addition to this we should make sure that wherever possible the scrollbars are given every last pixel up to the edge of the screen, so that they become, effectively infinite in width (or height, when horizontal), thus making them difficult to miss. Eben paul =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] seeking feedback on sketch of a new color selector
On Mon, Dec 7, 2009 at 12:39 PM, Gary C Martin g...@garycmartin.com wrote: Hi Walter/Simon, On 7 Dec 2009, at 10:37, Simon Schampijer wrote: On 12/06/2009 11:05 PM, Walter Bender wrote: On Sun, Dec 6, 2009 at 8:54 PM, Simon Schampijersi...@schampijer.de wrote: A few questions: - in the Feature page you mention the 'random selector', is this option still available in the latest design? This is still in the new design in that I didn't remove it from the code. (If you click on the central XO icon, you get a random color as before.) It is a decision I leave to the design team. Ok. Maybe the design team want to comment if they think that the random functionality is a good one to have. Sorry, not quite following the 'random functionality' comment. Just to check, my understanding that 'forwards' and 'backwards' are hooked up to change a seed value used for a random calculation of the fill/stroke colour choices (an almost infinitely large carousel of random choices, left or right). Where the buttons act something like the below image to maintain the current behaviour where clicking the large Xo icon still progresses forward: That's my understanding as well. I think that keeping it simple, with only next and previous controls, is probably the right way to go. Allowing a click to generate a new random color is essentially duplicate functionality, and without an obvious undo which is the hallmark of the new design in the first place. If we really want to retain functionality when clicking on the large XO (for familiarity to those who used the old design), we could treat it the same as a click on the next button. Eben Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] seeking feedback on sketch of a new color selector
On Mon, Dec 7, 2009 at 12:52 PM, Walter Bender walter.ben...@gmail.com wrote: On Mon, Dec 7, 2009 at 12:39 PM, Gary C Martin g...@garycmartin.com wrote: Hi Walter/Simon, On 7 Dec 2009, at 10:37, Simon Schampijer wrote: On 12/06/2009 11:05 PM, Walter Bender wrote: On Sun, Dec 6, 2009 at 8:54 PM, Simon Schampijersi...@schampijer.de wrote: A few questions: - in the Feature page you mention the 'random selector', is this option still available in the latest design? This is still in the new design in that I didn't remove it from the code. (If you click on the central XO icon, you get a random color as before.) It is a decision I leave to the design team. Ok. Maybe the design team want to comment if they think that the random functionality is a good one to have. Sorry, not quite following the 'random functionality' comment. Just to check, my understanding that 'forwards' and 'backwards' are hooked up to change a seed value used for a random calculation of the fill/stroke colour choices (an almost infinitely large carousel of random choices, left or right). Where the buttons act something like the below image to maintain the current behaviour where clicking the large Xo icon still progresses forward: Regards, --Gary Just to bring clarity to what I have implemented so far: (1) clicking on the left xo icon or the icon causes the color pair to cycle to the previous color pair in the list of colors found in xocolor.py (2) clicking on the right xo icon or the icon causes the color pair to cycle to the next color pair in the list of colors found in xocolor.py (3) clicking on the large xo icon causes a random color pair to be selected from the list in xocolor.py and resets the index used in #1 and #2. (Essentially the same as the present behavior). There is also a hidden button (a temporary kludge) to undo (useful for undoing the random selection). The intention is to associate a key (Ctrl-z) to the undo function. Of course, you can still back out of the whole thing by canceling the changes in the manner currently supported: hitting x instead of ✓ on the panel. Yeah, I wouldn't place too much home in an undo shortcut being discovered, but you're right about the ability to cancel in the settings panel. The same is not true, of course, on first start. Comments on the above: (a) The order of the colors in xocolor.py is reason to cycle through. If you get a close approximation from random, you can fine-tune your selection by searching through adjacent colors. Perhaps if we remove the random function, we could support press-and-hold to cycle more quickly through the color space. I do see the arguments for retaining random, of course, so maybe the implementation you have is the right one. (b) I don't know how to get icons that can both be recolored and use accelerator keys, hence the kludge above. For accessibility purposes, it would be nice to add short-cuts to all the buttons in the control panel. (c) Gary, I tried the stacked icons vs running them in a row. The stacked icons didn't do it for me (or Eben, as I recall). The current configuration is xo XO xo. Yeah, I think my preference was for: ( xo) XO (xo ) with the ( xo) units reacting as one big button. That is, you could click on either the XO or the arrow. I believe this is how it functions now, apart from the order of the xos and arrows being reversed. Another possibility would be to make that more explicit by using text/icon buttons, instead of just icons, like: ( xo Back ) XO ( xo Next) In other words, the buttons would be the usual pill-shaped gray buttons, with a colored XO for an icon and the word next or back. That would help reduce confusion about which XO is My XO. Eben -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] adding 3G devices support to sugar
On Thu, Dec 3, 2009 at 1:44 PM, Martin Abente mabe...@paraguayeduca.org wrote: Today i finished the systray device icon. (but i still need the icon graphic... any artist around?) I'd be happy to sketch some icons. Do you have any suggestions or examples of what an appropriate icon might be for a 3G modem? As far as I know, they come in all shapes and sizes—including, of course, cell phones—and I'm not sure there is an accepted or easily recognizable form for an icon. Eben So, now we have 1. Store settings with gconf 2. Configuring settings at control panel (thanks to Daniel Castelo) 3. Systray device icon fully working 4. Gsm connections management I still need to clean stuff on 1,3,4 Saludos, On Wed, 2 Dec 2009 10:43:51 -0200, Daniel Castelo dcastelo.sugarl...@gmail.com wrote: In Uruguay we need USB_SERIAL_OPTION for 3G Modems. Martin, I could test your work using 3G Modems. I could help programming the control panel and the device icon too. On Wed, Dec 2, 2009 at 10:31 AM, Martin Langhoff martin.langh...@gmail.comwrote: On Wed, Dec 2, 2009 at 3:04 AM, Martin Abente mabe...@paraguayeduca.org wrote: I have successfully extended jarabe/model/network.py, so we can load-in a gsm connection, tested it with my app (gsmbridge) and it works, tomorow ill clean up the code, add the control panel and the device icon part. Cool. Can you give us a list of kernel modules that will work with this, so we can look at building them for the XO1/1.5 kernels? They'll probably be split off in a separate rpm, but easily installable. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Activity as a regular Journal Object request for inclusion to 0.88
On Tue, Dec 1, 2009 at 5:54 AM, Martin Langhoff martin.langh...@gmail.com wrote: On Mon, Nov 30, 2009 at 9:40 PM, Wade Brainerd wad...@gmail.com wrote: When deleting an object from the Journal that is an activity bundle, we ought to display an alert with a scary icon. The alert should clearly state that Journal entries will no longer be able to be opened until the activity is reinstalled. Majority of 6 year old will not understand that. The best way to handle this, I think, is to let kids delete activities but also keep a reference to the source in the form of an update URL or similar, so that fetching the activity automatically when an instance of it is resumed can be done. There's additional UI work there, and we can't guarantee connectivity, etc., but it would help reduce the overhead involved. (I'm not suggesting we shouldn't find ways to make it clearer when a deletion is happening, either, but as noted, the dialog may not work in practice with the target audience.) Some of the other operations Aleksey mentioned, like upgrading activities, ought to display similar alerts. Gentlemen, alerts do not work with young users. We have to just DTRT, or provide actions that are very clearly different (and even then...). On a more general note, this discussion has many hints of the action/object views that have been tossed around for some time now. This specifically addressed the conflict between the desire to manage all objects and the desire to have the Journal reflect only the actions of the child. In this split, the action view shows actions, which reference one or more objects (activities, people, devices, etc.) This would contain only references to things the children have done themselves. The object view shows objects, which is a more traditional view of everything that's around to be manipulated. Any preinstalled activities would appear in the object view by default, and thus be accessible by kids to copy, share, modify, etc. (and as they do, new actions will be created to record that). Ultimately, the object view would look much like the current Journal view does, and the actions view would be a bit friendlier. One benefit of this is that young kids need only look at the actions view, while those that wanted more control could dig into the objects directly. Eben cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sharing in Terminal
On Sun, Nov 22, 2009 at 6:10 PM, Wade Brainerd wad...@gmail.com wrote: Hey Sayamindu, This sounds great to me! It was on my TODO list when I added tabs, but I never got around to attempting it. I too like the idea of shared tabs. The way I would do the UI is: When the Terminal activity is shared (either the Share toolbar button has been clicked, or the activity was launched in response to an invitation), an extra button appears in the Tabs toolbar: New Shared Tab Any user can click this button; tab that is created will be visible by all participants. The shared tab's title bar will be prefixed with the owner's buddy name and could even display their buddy icon. That sounds pretty good. It would actually be nice to have a Shared Tab control that rendered the tab itself in XO colors, instead of just putting the XO icon inside a generic tab. Eben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] another attempt at a color selector
Very nice! The ability to go backward is a huge improvement. I have a few thoughts on the layout. I'd suggest putting the arrows on the outside, with the smaller (presumably cell size) XOs just to the left and right of the large one. I'd also suggest making the arrow buttons smaller, so they don't overpower the interface (right now they actually appear larger than cell size; I think even showing them at the size they appear in the Journal, or in menus, might suffice). Finally, I can't tell if this works now or not from the video, but I'd suggest that clicking the arrow or the smaller XO icons should change the selection. Eben On Wed, Nov 11, 2009 at 12:41 PM, Walter Bender walter.ben...@gmail.com wrote: http://dailymotion.virgilio.it/video/xb44q3_color-selector-2_tech -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] seeking feedback on sketch of a new color selector
Very nice! The ability to go backward is a huge improvement. I have a few thoughts on the layout. I'd suggest putting the arrows on the outside, with the smaller (presumably cell size) XOs just to the left and right of the large one. I'd also suggest making the arrow buttons smaller, so they don't overpower the interface (right now they actually appear larger than cell size; I think even showing them at the size they appear in the Journal, or in menus, might suffice). I'm glad to see that clicking the arrows or the small XOs works! Eben On Wed, Nov 11, 2009 at 4:39 PM, Gary C Martin g...@garycmartin.com wrote: Hi Walter, On 11 Nov 2009, at 17:42, Walter Bender wrote: I just posted another version (no undo) and I think more clarity as to what is going on... You can click the buttons or the small XOs. Yes, fab, that's much clearer, even for a static view. Here's a quick mockup at keeping the large buddy icon central so it matches the usual zoom presentation of your buddy icon: Regards, --Gary -walter On Wed, Nov 11, 2009 at 12:31 PM, Gary C Martin g...@garycmartin.com wrote: Hi Walter, On 11 Nov 2009, at 15:48, Walter Bender wrote: I made a patch to the color selector on the About Me panel to make it a little easier to navigate the color selections. Please see my screen cast at http://dailymotion.virgilio.it/video/xb42um_color-selector_tech. I needed to watch through a number of times before I could work out the logic for the colours of the two smaller buddy icons. First couple of times through I thought one was a swapped fill/stroke, and the other was a 'light' version, then third time through I decided they must all just be random, finally I twigged that it was a scrolling history moving from right to left (small -- big -- small). Quick thoughts: - What you have now would be visually understandable after a single click if you added a brief transition animation so that the icons scroll left/right and resize (like a carousel). - Not convinced you need the undo icon if you can add the transition animation, it feels slightly odd at the moment that the undo is right next to the yet too be seen new colour combination (perhaps it could go above or below the centre icon if it really needs to stay in the design). - The alternative is to have N small buddy icons around the central large icon, where the small icons are a close variation of the central large icon colours. Clicking the centre icon picks a completely new random base set of colours; clicking any small icon moves it to the centre large position, and generates a new set of small variants. The colour variants could just be +/- small random steps from the main base colours, or have some spacial meaning (left/right could be +/- fill colour, up/down could be +/- stroke colour). Regards, --Gary -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ribbon, right-click, button bars (was: RFC: Kill the delayed menus for good)
On Tue, Oct 20, 2009 at 4:08 PM, Albert Cahalan acaha...@gmail.com wrote: Eben Eliason writes: palettes, we aimed to reduce accidental invocation of them without entirely eliminating discovery by increasing the delay. ... I'm more worried about immediately revealing of all secondary actions, which pull attention from the more efficient manner in which basic actions can be performed - namely, clicking on the big icons. If we can do this in a manner which doesn't distract from the primary interaction methods and encourage inefficient paths through the UI, that would be great. I believe this was first solved by Kid Pix, a few decades ago. One button bar swaps out another button bar. Microsoft's ribbon looks like the same thing, though I've never used it so I can't say for sure. Tux Paint certainly uses this model. In that case, it works fine for kids **way** below sugar's target age. (smart 2-year-old or regular 4-year-old for sure, possibly younger) Yeah. This is very similar to the now implemented redesign of the toolbar system for activities, which feedback has indicated is a huge improvement. However, it doesn't instantly solve the issue for freely positioned UI elements, such as people and activities within the various zoom levels. There may be a variation on the technique that could work in these contexts, of course, and some interesting possibilities have already been suggested. Another possibility would be to educate children about right click somehow. On the one hand, I think it's really important to do this. Besides the human-compatibility issue and the extra expressive power, I think using a second button will help to develop the mind a bit. (you're not just grabbing or poking when you click; you're performing an action that could be determined by which button you click) On the other hand, I think both buttons should be the left button by default. Kids have trouble hitting the correct button. Button mistakes should not be something kids face from the moment go. Yup. The hardware design was done before a UI team was organized at OLPC. One of the first suggestions, though it was already too late, was to limit the hardware to one button. Since we didn't have the opportunity to change that, we opted to provide a more traditional right-click functionality both because it did provide a way to offer more contextual actions in a manner consistent with other interfaces that already exist, and because we thought it could actually be perplexing to have two buttons that always appeared to do the same thing. If that's proving problematic for children in practice, we could make a change there. I hadn't heard much on that particular issue, so I don't know how common (or persistent) it is. Perhaps, as suggested by Wade, we could allude to the availability of more information immediately on hover, and perhaps even try making the right button the only means of invoking the secondary actions. This does work today, but the lack of discoverability is a definite problem. It's no less discoverable than the left button. Right-click menus True. need to work two ways though: a. Press and hold down right button, move, release b. Click (press and release) right button, move, click either button Agreed. This would be a good improvement to the behavior. Eben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Re: [Bugs] #1508 UNSP: confusing wording on download from Browse
Since the desire to stop the activity has already been conveyed by clicking the Stop button, the real choice to be made is whether or not the download should be cancelled. How about changing the wording to convey this choice directly: To stop the activity now now you must cancel your ongoing download. [Cancel download] [Continue download] Clicking [Cancel download] will cancel the download and stop the activity (as was already requested by clicking Stop). I chose to keep the word cancel in the Cancel download button because the term stop is used in the UI as an action which can be resumed, which is untrue of the download. Clicking on [Continue download] will cause the alert to disappear, and implicitly cancel the previously requested stop action on the activity. On Mon, Oct 19, 2009 at 9:54 AM, Walter Bender walter.ben...@gmail.com wrote: In this particular case, we may want to say: Continue with download Stop download and stop browsing This isn't bad either, though perhaps we could say the same in fewer words: [Continue download] [Cancel and stop] Eben -walter On Mon, Oct 19, 2009 at 9:09 AM, Wade Brainerd wad...@gmail.com wrote: Yeah, Stop and Don't Stop sound best to me. Cancel is almost never an appropriate button; we should grep the codebase for it :) On Mon, Oct 19, 2009 at 8:35 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Mon, Oct 19, 2009 at 13:32, Gabriel Eirea gei...@gmail.com wrote: How about Quit and Don't quit? That would be better, though activities are stopped, rather than quitted. Thanks, Tomeu 2009/10/19 Tomeu Vizoso to...@sugarlabs.org: Any ideas for a better wording? Thanks, Tomeu On Sat, Oct 17, 2009 at 00:40, Sugar Labs Bugs bugtracker-nore...@sugarlabs.org wrote: #1508: confusing wording on download from Browse --+- Reporter: walter | Owner: erikos Type: enhancement | Status: new Priority: Unspecified by Maintainer | Milestone: Unspecified by Release Team Component: Browse | Version: Git as of bugdate Severity: Trivial | Keywords: Distribution: Unspecified | Status_field: Unconfirmed --+- If you try to quit Browse in the middle of a download, you are told that quiting will cancel the download and you are presented with two buttons: cancel and stop. Hitting the stop button will cancel the download and hitting the cancel button will cancel the quitting, hence not cancel the download. I wonder if there are better words we can use to make this a bit less confusing. -- Ticket URL: http://bugs.sugarlabs.org/ticket/1508 Sugar Labs http://sugarlabs.org/ Sugar Labs bug tracking system ___ Bugs mailing list b...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/bugs -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] friendview.py
On Sat, Oct 17, 2009 at 9:40 AM, Wade Brainerd wad...@gmail.com wrote: Yeah, P2P activity sharing would be awesome. http://wiki.sugarlabs.org/go/Development_Team/Almanac/Activity_Bundles says Activities are meant to be shared between children. If a child doesn't have the activity, it is automatically transfered to the child when he or she joins the shared activity. but I don't believe this was ever implemented...? Right. To me, it sounds like the first step in building either of these systems (automatic p2p transfer, download from browse) is figuring out a way to publish the activity icon so that we DON'T have to show a question mark. I would much rather show the icon for the activity that the child doesn't have, and perhaps badge it in some way to indicate that they don't yet have it. This seems desirable regardless of which solution we choose to download the activity. Eben -Wade On Sat, Oct 17, 2009 at 9:35 AM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: Tim McNamara wrote: Naturally, people will probably want to click on that question mark. Would we be able to have a dialogue like Search for activity %s? % name, which if accepted opens up Browse and searches http://activities.sugarlabs.org to download it? That would be about ten times better than the current behavior. This would be easiest if you can p2p file share activities... I've played around a bit, but it doesn't look especially obvious. Yes, that would be, by far, even better. It shouldn't be incredibly difficult, since Telepathy provides us with a high-level file transfer operation, but there's still some code required to (1) request the transfer, (2) create a bundle if necessary, (3) transfer the bundle, (4) install the bundle, and then (5) launch it. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design mockup of a different activity launcher
On Sat, Oct 17, 2009 at 4:53 PM, Wade Brainerd wad...@gmail.com wrote: http://www.youtube.com/watch?v=OvDdN1t-0yE I was in the code and have wanted to try this for awhile! If anyone else thinks it would be better than the pulsing icon, I'll clean up and post the patch to a Feature on the wiki. Rationale: 1) Less flashy Perhaps, although the screen actually feels busier to me. Perhaps with some visual tweaks it would work (smaller ring, maybe?), since showing how long it will take to launch is useful feedback. I lament the loss of the pulsing icon, though. This approach doesn't retain the transition from outline to fill that's important to the activity paradigm. Could we retain that, or is that the flashy part you aim to eliminate? 2) Clock theme represents time I don't understand how we know how long the launch is going to take. Is that something that we can estimate to a reasonable degree? Or do you plan to estimate the average launch time across many launches? 3) Ability to count how many seconds the launch takes I'm not sure I see usefulness in knowing how long it takes overall; knowing how much longer it will take is definitely something a kid will want to know, though, so it's good to show that. 4) Close button (instead of timeout) when there is an error This is definitely a big improvement. I like this a lot, and think we should also add options for looking at the crash reports and/or submitting a bug containing them to the maintainer of the activity, eventually. 5) Possibly less startup overhead; needs to be tested on XO True. If CPU is a concern, I'd vote to simply blink the icon between stroke and fill states, instead of pulsing, in order to reduce the animation overhead while retaining the visual metaphor. Eben -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design mockup of a different activity launcher
On Sat, Oct 17, 2009 at 8:10 PM, Wade Brainerd wad...@gmail.com wrote: Hi Eben, thanks for the feedback! On Sat, Oct 17, 2009 at 7:27 PM, Eben Eliason e...@laptop.org wrote: On Sat, Oct 17, 2009 at 4:53 PM, Wade Brainerd wad...@gmail.com wrote: http://www.youtube.com/watch?v=OvDdN1t-0yE I was in the code and have wanted to try this for awhile! If anyone else thinks it would be better than the pulsing icon, I'll clean up and post the patch to a Feature on the wiki. Rationale: 1) Less flashy Perhaps, although the screen actually feels busier to me. Perhaps with some visual tweaks it would work (smaller ring, maybe?), since showing how long it will take to launch is useful feedback. I'm happy to make any tweaks to the layout, colors, sizes of the dots, spacing, etc. If design can provide a mockup, that would be great! But if not, I'm happy to take suggestions and try to improve it. I lament the loss of the pulsing icon, though. This approach doesn't retain the transition from outline to fill that's important to the activity paradigm. Could we retain that, or is that the flashy part you aim to eliminate? I wanted to stop drawing something big every frame while the activity is trying to start; that's the supposed performance improvement. Blinking would be fine, or a brief fade in at the beginning. Yup, I suppose both could work. The reason to blink, I suppose, is to illustrate the intermediate state throughout the launching phase. We use the same metaphor for connecting to networks, as well. 2) Clock theme represents time I don't understand how we know how long the launch is going to take. Is that something that we can estimate to a reasonable degree? Or do you plan to estimate the average launch time across many launches? No - the clock just displays one new dot per second. So an activity which launches in 3 seconds shows 3 dots. Oh, hmmm. That makes this a bit less useful, and even potentially misleading. I don't think it's a good idea to show a determinate progress indicator for something that takes an indeterminate length of time. Even if we mapped the ring to the time we wait before a fail launches, I think the visual would imply to the child that success, rather than failure, was imminent, which could be frustrating. I could implement some estimation capacity, but that would mean the dots appear faster or slower. I prefer to let the user see there is a different amount of work involved in starting each activity, instead of implying that the same amount of work is being done at a different rate. Hmm, it seems like you're arguing against the progress bar, as we know it. =) I guess it's just the difference between an absolute and a relative measure of progress, and the use of an absolute makes some sense if we can't know how long an activity is going to take to launch, but it still strikes me as the wrong metaphor. As I mentioned before, I think it's much more important to the child how much longer the launch will take (not how long it's taken so far). In either case, perhaps we can get the same type of feedback by counting the number of times an icon blinks. You could set the frequency to 1 second. 3) Ability to count how many seconds the launch takes I'm not sure I see usefulness in knowing how long it takes overall; knowing how much longer it will take is definitely something a kid will want to know, though, so it's good to show that. The way it's implemented now, the kid has to remember how many dots an activity takes to start up. But I think that could aid children who are learning to count :) (WARNING: Heresay!!) Heh. 4) Close button (instead of timeout) when there is an error This is definitely a big improvement. I like this a lot, and think we should also add options for looking at the crash reports and/or submitting a bug containing them to the maintainer of the activity, eventually. I did some work towards this, with a patch ready for 0.88, in http://wiki.sugarlabs.org/go/Features/Problem_Reports. I will definitely make it automatically save the activity log to the Journal, though. Actually, I don't think this should be automatic. I would recommend the options (report bug), (view logs), and (stop). This would give the child the option to look at the logs if they wanted, but wouldn't otherwise put items in their Journal they don't want or need. I'm not sure if reporting is possible given the current infrastructure, but it could be useful, in the long run. 5) Possibly less startup overhead; needs to be tested on XO True. If CPU is a concern, I'd vote to simply blink the icon between stroke and fill states, instead of pulsing, in order to reduce the animation overhead while retaining the visual metaphor. Blinking would definitely be ok. Yeah. It doesn't have quite the same appeal, but it would be less CPU intensive. Incidentally, how does the launcher perform on the XO 1.5 units? Has anyone had a chance to try
Re: [Sugar-devel] RFC: Kill the delayed menus for good
I wanted to include Christian on this thread since he may also wish to try it out and have some valuable feedback. It seems like this thread is somewhat split between design discussions and process issues. Should it be exclusive to the sugar-devel list? If we want feedback from people other than developers it seems we should have a broader scope. Eben On Thu, Oct 15, 2009 at 11:19 PM, Eben Eliason e...@laptop.org wrote: On Thu, Oct 15, 2009 at 10:09 PM, Avi fiendi...@gmail.com wrote: Tomeu wrote: I'm more concerned about developers proposing big user experience changes because they feel it's better. Before I look at the patch I would like to know if there's agreement from people close to our users that this behavior change is desired. How can we get that? How about users (me) proposing big user experience changes by asking a developer (Michael) why the fuck does this UI take so goddamned long to react? Also, define our users. Is it people using Sugar? Is it people using XOs? Is it people other than you? I'll gladly put myself into any of these categories if it makes you happy. I think we'd all agree that the primary audience for Sugar is children of varied age groups and levels of education, and that audience should be considered first in terms of the user experience. I'm not suggesting, of course, that the rest of us aren't also users with valid input and experiences, or that this proposed patch was submitted without the best interests of that audience, or at least a reasonable portion of that audience, in mind. I also don't believe that Tomeu was stating a challenge of any kind, or insinuating that no one other than Michael was likely to have a positive response to the proposed change. The suggestion was that we collect feedback from many people, yourself included, and also from children in our primary audience and the teachers and instructors who work with them daily. In that regard, thank you for your feedback; it would be more constructive, of course, if you could provide it without the profanity and apparent disgust. Eben wrote: The initial design intent was to develop a system which worked in a sufficiently complete manner without needing palettes at all. 1) For whom? What about people who know how to recognize English letters and words better than they remember what an obscure picture means? Because you've failed on that front. For children! And actually, I agree with you. In many cases text is minimized more than I would like it to be. Clearly it's beneficial for those learning to read to see associations of words and icons, and words are naturally useful to those who already can. 2) Good luck. Sincerely. I hope that if that's still your goal that it's actually possible. I'm personally not convinced, but only because I haven't yet seen a demonstration that shows progress on that front. Honestly, I think we've come relatively close. Would you strongly disagree? It's possible to create new activities, resume past activities, join collaborative activities, connect to networks, participate in activities, copy, paste, and stop activities with the use of primary actions only. I'm not suggesting that the full power of the UI is available without the need for seeing any text, but I am suggesting that there are a great many things you can do with Sugar without needing to use the secondary actions and tools available in palettes. If there are basic functions or actions that are frequently needed that aren't exposed as primary actions, it would be useful to identify those areas in order to make improvements. Do you have any suggestions? Finding that many kids were actually waiting for the palette to appear always, instead of, for instance, simply clicking on an activity icon to join it, encouraged us to INcrease the delay on the palettes to help emphasize this as a secondary mechanism for interaction. Jesus, why? Think about what you just said for a moment. Why might someone wait for the palette to appear before clicking? Probably because they want to see what's on the palette! The situation of the palette is that all it I was not precise enough in my statement. Upon observation, many children were waiting for the palette exclusively to select the first option within it, which is the primary action that a click on the object itself would also invoke. They were NOT attempting to access the secondary functionality, but instead, due to the appearance of the palette, assumed that this was the only means of interaction. As Michael correctly points out, the contextual menus are indeed an inferior solution to direct interactions, since they require finer motor skills (and are difficult with poor trackpads, such as those on XOs) and movement away from the object they wish to interact to a secondary target within the menu. The icons are larger targets, easy to click without delay, and would have saved children both time
Re: [Sugar-devel] RFC: Kill the delayed menus for good
On Thu, Oct 15, 2009 at 10:09 PM, Avi fiendi...@gmail.com wrote: Tomeu wrote: I'm more concerned about developers proposing big user experience changes because they feel it's better. Before I look at the patch I would like to know if there's agreement from people close to our users that this behavior change is desired. How can we get that? How about users (me) proposing big user experience changes by asking a developer (Michael) why the fuck does this UI take so goddamned long to react? Also, define our users. Is it people using Sugar? Is it people using XOs? Is it people other than you? I'll gladly put myself into any of these categories if it makes you happy. I think we'd all agree that the primary audience for Sugar is children of varied age groups and levels of education, and that audience should be considered first in terms of the user experience. I'm not suggesting, of course, that the rest of us aren't also users with valid input and experiences, or that this proposed patch was submitted without the best interests of that audience, or at least a reasonable portion of that audience, in mind. I also don't believe that Tomeu was stating a challenge of any kind, or insinuating that no one other than Michael was likely to have a positive response to the proposed change. The suggestion was that we collect feedback from many people, yourself included, and also from children in our primary audience and the teachers and instructors who work with them daily. In that regard, thank you for your feedback; it would be more constructive, of course, if you could provide it without the profanity and apparent disgust. Eben wrote: The initial design intent was to develop a system which worked in a sufficiently complete manner without needing palettes at all. 1) For whom? What about people who know how to recognize English letters and words better than they remember what an obscure picture means? Because you've failed on that front. For children! And actually, I agree with you. In many cases text is minimized more than I would like it to be. Clearly it's beneficial for those learning to read to see associations of words and icons, and words are naturally useful to those who already can. 2) Good luck. Sincerely. I hope that if that's still your goal that it's actually possible. I'm personally not convinced, but only because I haven't yet seen a demonstration that shows progress on that front. Honestly, I think we've come relatively close. Would you strongly disagree? It's possible to create new activities, resume past activities, join collaborative activities, connect to networks, participate in activities, copy, paste, and stop activities with the use of primary actions only. I'm not suggesting that the full power of the UI is available without the need for seeing any text, but I am suggesting that there are a great many things you can do with Sugar without needing to use the secondary actions and tools available in palettes. If there are basic functions or actions that are frequently needed that aren't exposed as primary actions, it would be useful to identify those areas in order to make improvements. Do you have any suggestions? Finding that many kids were actually waiting for the palette to appear always, instead of, for instance, simply clicking on an activity icon to join it, encouraged us to INcrease the delay on the palettes to help emphasize this as a secondary mechanism for interaction. Jesus, why? Think about what you just said for a moment. Why might someone wait for the palette to appear before clicking? Probably because they want to see what's on the palette! The situation of the palette is that all it I was not precise enough in my statement. Upon observation, many children were waiting for the palette exclusively to select the first option within it, which is the primary action that a click on the object itself would also invoke. They were NOT attempting to access the secondary functionality, but instead, due to the appearance of the palette, assumed that this was the only means of interaction. As Michael correctly points out, the contextual menus are indeed an inferior solution to direct interactions, since they require finer motor skills (and are difficult with poor trackpads, such as those on XOs) and movement away from the object they wish to interact to a secondary target within the menu. The icons are larger targets, easy to click without delay, and would have saved children both time and aggravation had they learned to act upon them directly. takes is one accident to discover that hovering shows useful information. And with the knowledge that the palette shows useful information, and that hovering shows the palette, it is reasonable that one might just engage in the described behavior. Either make the useful information available without the contextual menu or make the current expected behavior more responsive. I think it may be useful to show the
Re: [Sugar-devel] RFC: Kill the delayed menus for good
On Wed, Oct 14, 2009 at 12:04 PM, Simon Schampijer si...@schampijer.de wrote: On 10/13/2009 04:36 AM, Bernie Innocenti wrote: Hello, Michael just passed by the Acetarium and, since the dinner was late, we found the time to test and review his latest prototype^W patch. I'm loving how the menus suddenly are now snappy and responsive. Please, test it yourself and report back. If we like this change, I think we should go on and also kill the code that this patch makes redundant. (please, let's not add another configurable knob!) From 83ef08969ed7bee08f90c12bfa1eedcb7fb0500c Mon Sep 17 00:00:00 2001 From: Michael Stonemich...@laptop.org Date: Mon, 14 Sep 2009 22:33:12 -0400 Subject: Make various palette animations happen more quickly. Can you describe what the patch will change from the user point of view? Is this to get rid of the delayed build up of palettes when hovering over icons? You can use right click to get the menu immediately. The delay is on purpose. We should definitely get feedback. I wouldn't be entirely opposed to a change, but I do want to make sure that we make such a change for the right reasons, and that it's actually the right change to make. The initial design intent was to develop a system which worked in a sufficiently complete manner without needing palettes at all. Kids should be able to start activities, resume activities, join activities, write, paint, stop, etc. without ever seeing a palette at all. [1] This is the low floor. For kids with more experience or curiosity, we decided to provide contextual palettes which grouped related actions and provided more complex interactions with the system. This is no ceiling. Furthermore, we wanted to help introduce kids to the availability of additional options in a discoverable way, which is why the hover effect was chosen to provide increasing levels of detail and interaction for a given object. Finding that many kids were actually waiting for the palette to appear always, instead of, for instance, simply clicking on an activity icon to join it, encouraged us to INcrease the delay on the palettes to help emphasize this as a secondary mechanism for interaction. A agree that hovering in one place to click in another isn't great; but that's also not the intended primary means of interaction, and should only really be done when one of the secondary actions is desired. Removing the delay pushes us, I fear, even farther away from an interface in which nice friendly large clickable icons can be directly manipulated and encourages every action to be done through a contextual menu with a bunch of text in it. Is that really what we want kids to face? Just for fun, I might suggest an alternate possibility which actually decreases the discoverability of the secondary palette. We could reveal the primary palette (label) on a delay as we do now, with some indication of more options that can be clicked to expand the menu to reveal the secondary items. This would provide the (essential) primary palette as a label and introduce kids to the existence of more controls without encouraging them to use this as a primary method of interaction. Advanced users, of course, could still right-click to invoke the full menu in one shot. Eben [1] Incidentally, one of my major complaints with the resume by default behavior is that it makes starting new activities hard to do, and virtually impossible to do without using a secondary action, which is the wrong approach in my mind. I think starting from home, with the option to resume, while encouraging one-click resume from the Journal is still the correct approach. I think offering the option to enter resume by default mode is great, but I'm not sure it should be, itself, the default for Home view. In practice, it seems it has worked too well. It used to be that kids never resumed activities. Now, it seems, they never start new ones. The solution seems to be in encouraging use of the Journal and the Home view for these different default actions, and in clarifying the UI such that kids understand and desire to do so. Eben Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] RFC: Kill the delayed menus for good
On Wed, Oct 14, 2009 at 1:41 PM, Edward Cherlin echer...@gmail.com wrote: I'm extracting some of the for [[The Undiscoverable]]. On Wed, Oct 14, 2009 at 9:39 AM, Eben Eliason e...@laptop.org wrote: On Wed, Oct 14, 2009 at 12:04 PM, Simon Schampijer si...@schampijer.de wrote: On 10/13/2009 04:36 AM, Bernie Innocenti wrote: Hello, Michael just passed by the Acetarium and, since the dinner was late, we found the time to test and review his latest prototype^W patch. I'm loving how the menus suddenly are now snappy and responsive. Please, test it yourself and report back. If we like this change, I think we should go on and also kill the code that this patch makes redundant. (please, let's not add another configurable knob!) Works for me. I hate hover menus. From 83ef08969ed7bee08f90c12bfa1eedcb7fb0500c Mon Sep 17 00:00:00 2001 From: Michael Stonemich...@laptop.org Date: Mon, 14 Sep 2009 22:33:12 -0400 Subject: Make various palette animations happen more quickly. Can you describe what the patch will change from the user point of view? Is this to get rid of the delayed build up of palettes when hovering over icons? You can use right click to get the menu immediately. The delay is on purpose. Yes, that's in [[The Undiscoverable]] We should definitely get feedback. I wouldn't be entirely opposed to a change, but I do want to make sure that we make such a change for the right reasons, and that it's actually the right change to make. The initial design intent was to develop a system which worked in a sufficiently complete manner without needing palettes at all. Kids should be able to start activities, resume activities, join activities, write, paint, stop, etc. without ever seeing a palette at all. [1] That's fine, if 1) Everything is discoverable. Yes, we could use some work there. The hover was meant to increase discoverability, not decrease it, but perhaps it's not working effectively. or 2) Teachers have guidance on what is not discoverable and how to introduce it, and on children's use cases and on how to handle those use cases efficiently. Agreed. We have neither. I'm working on 2. Anything that improves 1 gets +1 from me. This is the low floor. For kids with more experience or curiosity, we decided to provide contextual palettes which grouped related actions and provided more complex interactions with the system. This is no ceiling. Furthermore, we wanted to help introduce kids to the availability of additional options in a discoverable way, which is why the hover effect was chosen to provide increasing levels of detail and interaction for a given object. Was the discoverability of hover menus tested with children? I didn't discover it, and I'm a born lever puller and button clicker. Almost nothing was tested with children until the first release of Sugar on the XO-1, unfortunately; we would have liked to test more. Finding that many kids were actually waiting for the palette to appear always, instead of, for instance, simply clicking on an activity icon to join it, encouraged us to INcrease the delay on the palettes to help emphasize this as a secondary mechanism for interaction. A case of treating the symptom rather than the ailment. Perhaps. What would you define as the ailment, yourself? The primary intent was to encourage use of a direct interaction model, in which palettes we're supposed to play a big role. When it turned out that young kids, who didn't read, and who didn't have motor skills for selecting form the palettes, we aimed to reduce accidental invocation of them without entirely eliminating discovery by increasing the delay. Perhaps (assuming, of course, the rules you laid out above already) we should remove the hover activation altogether! (Not, of course, without testing!) A agree that hovering in one place to click in another isn't great; but that's also not the intended primary means of interaction, and should only really be done when one of the secondary actions is desired. Removing the delay pushes us, I fear, even farther away from an interface in which nice friendly large clickable icons can be directly manipulated and encourages every action to be done through a contextual menu with a bunch of text in it. Is that really what we want kids to face? I don't see the problem. The nice friendly large clickable icons will remain where they are. You either have to create and *demonstrate* a path to *equal* discoverability, or you have to think about helping teachers help children with what they don't discover. The problem is that the appearance of the palette seems to encourage kids to take the longer (and harder) route to their desired interaction. The reveal of the alternate option could distract from the more direct path to their intended goal. Again, observation with kids indicated that, even without revealing palettes immediately, they tended to wait for them instead of clicking directly
Re: [Sugar-devel] RFC: Kill the delayed menus for good
On Wed, Oct 14, 2009 at 11:12 PM, Michael Stone mich...@laptop.org wrote: Eben, First, thanks for the interesting and detailed history of your vision. I very much appreciate your ability to generate thought experiments describing other ways that the world could be. Next... Eben wrote: Simon Schampijer si...@schampijer.de wrote: You can use right click to get the menu immediately. The delay is on purpose. We should definitely get feedback. I wouldn't be entirely opposed to a change, but I do want to make sure that we make such a change for the right reasons, and that it's actually the right change to make. So try it, and encourage your friends to do the same! :) I don't feel inclined to myself, as I've never had a problem with the delay, and actually used to find the speed with which these palettes obstructed my view of the screen frustrating before the delay was increased. I assume there is a group of individuals — developers and kids alike — who feel the same as I do, and others who feel the same as you. Those that feel as you do, of course, should definitely try it and provide feedback, which I'd be happy to hear. I have no itch. (NB: merging it is a good way to accomplish this!) The initial design intent was to develop a system which worked in a sufficiently complete manner without needing palettes at all. Kids should be able to start activities, resume activities, join activities, write, paint, stop, etc. without ever seeing a palette at all. [1] This is the low floor. For kids with more experience or curiosity, we decided to provide contextual palettes which grouped related actions and provided more complex interactions with the system. This is no ceiling. Furthermore, we wanted to help introduce kids to the availability of additional options in a discoverable way, which is why the hover effect was chosen to provide increasing levels of detail and interaction for a given object. This is a good story, but a bad implementation. A better implementation would be to provide the extra options in a *visible but unobtrusive I disagree that this is an obviously better implementation. It's better if you're one who frequently has needs for the additional complexity. It's arguably not if you use only (or mostly) primary actions. form* or, if you absolutely must hide them, to make them visible with a device like a complexity slider or like the new toolbar's transient hover; lock on click behavior. Adding a preference for the delays for these palettes, as we have for the frame, is a another reasonable possibility, and a literal incarnation of the complexity slider you suggest. Remember -- comparisons should be made in a fixed visual field, not across multi-second long gulfs of time, cursor positioning, and fine motor control. Finding that many kids were actually waiting for the palette to appear always, instead of, for instance, simply clicking on an activity icon to join it, encouraged us to INcrease the delay on the palettes to help emphasize this as a secondary mechanism for interaction. A agree that hovering in one place to click in another isn't great; but that's also not the intended primary means of interaction, and should only really be done when one of the secondary actions is desired. Understandable, but as you say, the result isn't great. This makes it better. Try it! Merge it! (Then come up with something better.) We had lots of trouble with palettes obscuring other elements of the UI even with short delays, including, potentially, the desired target. I can't imagine that this issue has gone away in the intervening months, and removing the delay entirely seems it would exacerbate the issue. Do you have any experiences to report in this regard? Removing the delay pushes us, I fear, even farther away from an interface in which nice friendly large clickable icons can be directly manipulated and encourages every action to be done through a contextual menu with a bunch of text in it. Is that really what we want kids to face? It's better than the present. Again, merge it, then find something better. You keep saying it's better, but fail to provide adequate reasoning or heuristics for why you feel this to be so. Could you elaborate on the problems you identified and the way in which this resolves them? Also, again, it's only arguably better (though I don't fully comprehend the argument) for those that want or need all of the secondary functionality, yourself included, and the ability to right-click to invoke palettes immediately exists to enable those who feel more comfortable with the system and desire the added level of depth it can provide to access these options without the delay. Just for fun, I might suggest an alternate possibility which actually decreases the discoverability of the secondary palette. We could reveal the primary palette (label) on a delay as we do now, with some indication of more options that can be clicked
Re: [Sugar-devel] New Sugar theme for Activity Library
Cool! A few comments: 1. I don't really like the way that Activities is positioned as a superscript after the Sugar logo. I think that activities could follow on the line below the Sugar logo, left aligned (there may be other equally good options). 2. The green interspersed throughout threw me off a bit. The styleguide for Sugarlabs pages, as I understand it, is a two-tone color scheme (in addition to the grayscale) inherited from the logo, so that all of the content and links share the colors in the logo on the page. If we could fix that, especially in the menu on the left, I think it would tie in with the other pages better. 3. The link hover style on other Sugarlabs pages is usually to invert the foreground and background colors, which usually means white text against the dark logo color. This is another change that we could integrate throughout to add consistency to the theme. Good work! Eben On Fri, Oct 9, 2009 at 2:25 AM, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, Josh Williams finished new Sugar theme for Activity Library(ASLO), please test it from [1]. Thanks Josh, it looks awesome. In several days ASLO code base will be rebased to last AMO, (it should give us new AMO features like tagging and new developers UI) and new theme will appear on the main site. [1] http://activities-devel.sugarlabs.org/ -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ASLO layout issue in safari
On Fri, Oct 9, 2009 at 1:43 PM, Josh Williams j...@tucson-labs.com wrote: Sean DALY wrote: Our websites really shouldn't make any assumptions about what browser our visitors are using... Agreed. Point taken. Would you or anyone else be opposed to using something like http://code.google.com/p/universal-ie6-css/ for ie6? This will provide access to all of the application's content (but save a considerable amount of development time for me). Sean, you have analytics set up on ASLO now right? If so can you share our visitors browser statistics? Yeah, that would be worth looking into. While I don't think we should make assumptions about which browsers visitors will use, I also don't think we necessarily need to jump through hoops to support backwards compatibility in older and entirely non-compliant (in terms of web standards) browsers. (Specifically, I'd suggest not worrying about IE6, if we can avoid it.) That said, I'd fully expect all our pages to work in any modern standards compliant browser, such as FF, Safari, and Chrome, and we should probably make sure that IE 7,8 also work smoothly. The statistics will be enlightening, I'm sure. Eben -Josh Sean On Fri, Oct 9, 2009 at 7:32 PM, Josh Williams j...@tucson-labs.com wrote: Hi Caroline, Thanks for the feedback! I actually wasn't planning on making this a cross web browser upgrade, but only for gecko/browse. If there's a general consensus that it should be bug free for other browsers, I can see the reasoning for that and I'm willing to make it work. I'm guessing you'd like to see it work in safari/ie/chrome/opera as well? If others want to chime in please do so. -Josh Caroline Meeks Fri, 09 Oct 2009 05:13:06 -0700 Nice! Here is a layout issue on Safari on a mac: http://screencast.com/t/Fyu8zoqjzfyu On Fri, Oct 9, 2009 at 2:25 AM, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, Josh Williams finished new Sugar theme for Activity Library(ASLO), please test it from [1]. Thanks Josh, it looks awesome. In several days ASLO code base will be rebased to last AMO, (it should give us new AMO features like tagging and new developers UI) and new theme will appear on the main site. [1] http://activities-devel.sugarlabs.org/ -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Sucrose 0.86 Branching - Activity versions
On Thu, Oct 1, 2009 at 7:16 AM, Peter Robinson pbrobin...@gmail.com wrote: On Thu, Oct 1, 2009 at 12:08 PM, Wade Brainerd wad...@gmail.com wrote: On Thu, Oct 1, 2009 at 5:20 AM, Simon Schampijer si...@schampijer.de wrote: *Activity versions* As we use integers for activity versions (this really has to change for 0.88 with introducing minor versions), we need to cope for the famous: stable/unstable version issue. I would say to leave at least 3 version numbers open when doing a new unstable release. An example: Walter has submitted TurtleArt 69 for 0.86. He reserves the numbers 70, 71, 72 for bug fix releases. When he is doing a release from the unstable master branch (0.88 development) he is using numbers 72. This still seems pretty limiting. What if he finds he actually needs 4 bugfix releases? Why should replace a limited system with another that's just as limiting (This suggestion is kind of like going from O(0) to O(3), instead of O(n) like we really need). I'm still against this plan. Does anyone else feel like the integer numbers are a good thing? I think it's been argued that it would be easier for kids, though I've counter-argued that it's harder to make sense of integer versioning when it's just more confusing to attempt to map the natural numbers onto a non-linear space. The decimal notation helps make the branching more visible, which adds clarity in addition to complexity (and it's clear the complexity can't be gotten rid of). We have been striving to keep activity releases backwards compatible as far as possible; there should be no need to branch activities for sucrose releases. If a bug is found, sucrose can be updated to the latest version. I agree. why not have 69 as the primary release and fixes against it for the branch as 69.1 69.2 etc. Or if its meant for a particular This definitely makes the most sense to me. I think that the major/minor distinction, where each portion of that version number is monotonically increasing, will keep things relatively simple without being too limiting. You can argue for major.minor.bugfix, too (which is more like O(n^2)), but chances are we'd all rather avoid that if possible. Of course, we could simply support version strings of this kind, but collectively agree to avoid the third field unless it's absolutely necessary. If we really want to keep integer version numbers, perhaps we should just multiply by 10 and allot versions 10 at a time, so that major releases would go from 60 to 70 to 80, etc, leaving 9 (yes, still just a constant, O(9)) bugfix releases open per major version, but allowing us to talk about activities as the 60s or 70s instead of keeping track of which 3 or so versions run on which platform. It's worth noting that this would get us into 4 digit version numbers a lot faster, of course. It could be a terrible idea, but I'm just throwin' it out there. Eben version of sugar and not meant to be compatible with earlier versions use the same release as the release of sugar. It would at least be easy to work out that version 86.x is needed for sugar 0.86.x as 69 has no relationship what so ever. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Colors in the rim (Re: sugaronastick.com (was Re: Beta Test of Sugar on a Stick Backup Service.))
There just aren't enough possibilities for uniqueness with only one color. The pair as an identifier of the individual needs to stay, I think. We could, perhaps, expose that kind of information in the secondary palette for XOs since it seems it would serve a purpose for some. I don't think it's a detail kids are going to need much, especially in local groups or schools where the distribution will be the same, so I wouldn't expose it more than necessary. Out of curiosity, to what extent is this a problem? Most activities should function fine across distributions, I would think. Eben On Thu, Sep 17, 2009 at 10:32 PM, Thomas C Gilliard satel...@bendbroadband.com wrote: Luke: I am thinking more of the usage case of community jabber users. (There are differences in how different distributions applications collaborate and function.) One could then know which features are available if you invite someone to an activity. This would be more useful in a non- XS situation where all people on the neighborhood are not using the same Sugar-Desktop. Thus by looking at the rim color a Sugar User would immediately have this information. The inside color of the XO would still be chosen by the user, and be variable. Tom Gilliard Luke Faraone wrote: On Thu, Sep 17, 2009 at 18:35, Thomas C Gilliard satel...@bendbroadband.com wrote: I also wish that the range of rim colors available for the XO choice in F1 Neighborhood would distinguish what Distribution they are based on... I'm just curious, but how is this relevant to the end user? Most students probably wouldn't care about what distro their friends are using. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Calculate toolbars work in progress shots
Looks great! The icons are quite nice. My only suggestion is that (still retaining the modularity!) the misc toolbar actually just be added as another secondary toolbar. That leaves the basic toolbar mostly empty, but that's ok! This is an instance, I think, where all of the basic functionality of the calculator lives outside of the toolbar, and each toolbar adds advanced functionality on top of that. Moreover, misc controls seem to be the worst suited for a primary toolbar, which should instead contain controls that are nearly always useful, or useful in all contexts. Eben On Fri, Sep 11, 2009 at 2:59 PM, Gary C Marting...@garycmartin.com wrote: Here's a quick set of screen grabs of a patch for Calculates toolbars, I'm making the code work for 0.82, 0.84 (keeping old style tab toolbars), and 0.86 (new style toolbars). To keep high re-use and minimum changes of code between the two toolbar styles, I'm using the same code for generating each toolbar, and the old 'Miscellaneous' tab content is being shown in the primary new toolbar design. Give me a shout if you have any feedback! I'll push my changes to a git clone of Calculate later tonight (all things going well): Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Calculate toolbars work in progress shots
On Fri, Sep 11, 2009 at 3:17 PM, Gary C Marting...@garycmartin.com wrote: Hi Eben, On 11 Sep 2009, at 20:11, Eben Eliason wrote: Looks great! The icons are quite nice. My only suggestion is that (still retaining the modularity!) the misc toolbar actually just be added as another secondary toolbar. That leaves the basic toolbar mostly empty, but that's ok! This is an instance, I think, where all of the basic functionality of the calculator lives outside of the toolbar, and each toolbar adds advanced functionality on top of that. Moreover, misc controls seem to be the worst suited for a primary toolbar, which should instead contain controls that are nearly always useful, or useful in all contexts. Thanks, that's pretty much where I was at but wanted another opinion :-) The one exception (for the future) will I hope be the Plot function. I'd love to see that UI improved via a Secondary toolbar, at the least with a set of standard example graphs for folks to plug in values (now that matplot lib is supported). Yeah, definitely. It would make sense to have a toolbar dedicated to that. I could also see dedicating a toolbar to constants. You've got buttons for a couple of them. Perhaps a few more could be added. If some don't have obvious symbols or frequent use, the constants toolbar could also have a dropdown that read add a constant by default, and contained a list of many with full names to add. A suggested symbol for this would follow the trend of the color and shape icons in the mockup of the Paint activity, which showed a small 2x2 grid of colors and shapes, respectively. I'd use e, pi, phi, and something else. If constants and graphs had their own secondary toolbars, I could see an argument for exposing the display mode in the primary toolbar, since it affects all calculations and could be useful to see at all times. Any suggestions for a Misc icon? ;-) I don't, unfortunately, have a good idea for a generic misc icon. It seems like any option I can think of I would consider bad design, which might be because using the concept of leftovers to group together a set of tools in a toolbar is just a bad idea. Heh. But short of breaking out the functionality as described above (which itself could seem odd without more functions in each toolbar), I don't have a better idea. I could get behind leaving the modes and the graph button up there for now if we could find a few more constants to add to a secondary constants toolbar and leave it at that. What do you think? Eben Regards, --Gary On Fri, Sep 11, 2009 at 2:59 PM, Gary C Marting...@garycmartin.com wrote: Here's a quick set of screen grabs of a patch for Calculates toolbars, I'm making the code work for 0.82, 0.84 (keeping old style tab toolbars), and 0.86 (new style toolbars). To keep high re-use and minimum changes of code between the two toolbar styles, I'm using the same code for generating each toolbar, and the old 'Miscellaneous' tab content is being shown in the primary new toolbar design. Give me a shout if you have any feedback! I'll push my changes to a git clone of Calculate later tonight (all things going well): Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [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!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Memorize create icon
On Fri, Sep 4, 2009 at 3:27 PM, Caroline Meekscarol...@meekshome.com wrote: On my wish list is the ability to combine tiles from different students. So each student could do a couple of States then you could play a game with all the states by sharing tiles from the whole class. That would be pretty awesome. It might be (relatively) easy to allow collaborative creation of tiles, with each child's display showing their own creator screen, but a shared collection of tiles. Whether or not that would be clear enough to be usable is another question. I suppose the tiles would/could be colored according to their creator while in create mode, which would certainly help. Another issue is what to do about identical answers. For instance you make a math game. 2+2 = 4 and 1+3 =4 but right now if you click on the wrong 4 I don't think it matches. This problem is fairly easy to solve technically, but actually rather advanced to expose to kids in the creation UI. It requires identifying equivalence classes of pairs (one equivalence class, as per your example, would contain both (2+2, 4) and (1+3, 4)). The pairs in these equivalence classes many or may not be ordered, which would be another complex choice to require of the user. That is, 1+3 = 2+2, but it is likely the intent of the creator to always match an expression to a value. An equivalence class defined having pairs (2+2, 4) and (4, 1+3) is correct mathematically, but would still yield unexpected matches in play. Alternatively, the items in the equivalence class could be treated individually instead of in pairs, eg. (2+2, 1+3, 4, 4), in which case any item in the class can be matched to any other. This, again, may not actually be desired. Eben Thanks, Caroline On Fri, Sep 4, 2009 at 2:35 PM, Joshua N Pritikin jpriti...@pobox.com wrote: On Fri, Sep 04, 2009 at 10:55:10AM -0400, Walter Bender wrote: To whomever is going to make these invasive changes, there are some rendering bugs in Memorize as well. Images should be centered in the tiles; presently they are justified to the top of the tile. Also, we should probably use a drop shadow for the text so that white text on white image problems are circumvented. I'd also like an option to play with all the tiles uncovered. Memorization is hard enough without needing to temporarily memorize the locations of all the tiles. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Friends view UI affordances?
On Wed, Sep 2, 2009 at 10:01 PM, Caroline Meekssolutiongr...@gmail.com wrote: My vision is that we would create Moodle Classes for all the various groupings that students have throughout the day. Then maybe the Neighborhood view shows only people who share a group with you, or maybe those people get preference if the Neighborhood gets too crowded. I think giving preference to people one knows/interacts with is a logical approach. On the Friends view it might be useful to pick just one of these groups. So if I'm in Reading Group A right now I could choose Reading Group A in a drop down in the friends view and it would show only people in my reading group. Later I am in Mr. J's Afterschool club and I pick that so I can work with them. After that I'm in homework time and I want to work on my Reading Group, I can use this to easily see if anyone else from my Reading Group is around to work on the homework assignment with. +1. This has been our intent for the groups view all along, and the lack of groups (naturally) has left it mostly useless. I think we should retain the ability to make friends, who should also appear in the view (and give it some utility until the rest is built), but the ability to filter the view to see and interact with specific groups of individuals is key to the collaborative experience. We had an ambitious view of what groups should be in the absence of a server, before Moodle was investigated. Perhaps we can start with a moodle approach and merge/sync that with a server-less approach later. Or perhaps the server-less ideal isn't actually needed, and Moodle is the appropriate means of introducing this much desired feature. Eben On Mon, Aug 31, 2009 at 11:46 AM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: Christoph Derndorfer wrote: On Mon, Aug 31, 2009 at 5:03 PM, Walter Bender walter.ben...@gmail.comwrote: 5. Automatically add anyone with whom you have been collaborating to the Friends view. (Doesn't quite solve the problem Michael describes, but it will result in a populated view. And it is easy enough to delete entries.) Personally I'm very much opposed to doing something like this without the user's explicit consent, especially since this is quickly going to result in a very cluttered friend's view. I agree... unless we rename it to something like the Recent Friends view. It could simply show, say, the 20 people with whom we have most recently collaborated. This would discard existing functionality in favor of different, new functionality. I suspect that this would still be an improvement, and that the current Friends view is little-used, but it would be nice to have confirmation from deployers before tearing out that feature. Ideally, both of these functions could coexist in the context of the Groups View, but we have only the vaguest mockups of how Groups should function, and even less of a blueprint for implementing them. --Ben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Ad-hoc network identification badge
On Fri, Aug 28, 2009 at 5:41 PM, Gary C Marting...@garycmartin.com wrote: On 28 Aug 2009, at 21:51, Eben Eliason wrote: On Fri, Aug 28, 2009 at 4:16 PM, Gary C Marting...@garycmartin.com wrote: On 27 Aug 2009, at 22:24, Simon Schampijer wrote: On 08/27/2009 10:42 PM, Gary C Martin wrote: Quick ping, Do we need something like an emblem-buddy.svg for ad-hoc network icons (e.g. an XO icon used in same way as the star and lock icon are used to badge AP icons)? Sorry couldn't find a trac ticket or the right ML thread. Regards, --Gary Yeah, I think we settled on a badged AP icon. If you have something in mind - please share it with us ;p OK :-) Just tested the buddy icon pretty much as is for an emblem, but it doesn't quite ring true (feels too fussy). Here's a few screen shots: So taking a leaf out of the emblem-locked style and came up with what I think is a much better emblem using a box outline and solid stroke colour for the buddy icon: Yup. I would definitely recommend the (unstroked, as you show it) XO icon within the box, as well. The badge feels just a little high in your mockups (it should be at a 45 degree angle from center, and positioned so that the lower-right corner falls outside the 55px recommended icon region, at (70,70)), but that's just an issue of defining the hotspot correctly. I copied the existing emblem-locked.svg positioning without falter, so assume this is the emblem placing code that's a little off (unless emblem-locked is wrong). Also, all bages are supposed to be black fills with white strokes (and white symbols within the box, eg. the XO itself). I think that never happened because entity support was never added for badges. Oh, OK. So black box (white stroke?) with white buddy icon (in this example) is the intention? Yup, these look great! Does someone know how to add that so we can fix the badges up? Alternatively, does someone want to update all of the default SVGs for the badges so that they use the correct colors without use of entities? Well the one's I've looked at have stroke_color and fill_color so it could just be a simple code change I guess (above screen shot was taken just by Right. I made them with the proper entities, but the code path for creating the badges isn't tied into the Sugar classes that do the entity replacement (or something like that). So we'd have to look into the badging code to see how to hook that up. changing stroke to white, and fill to black). But I can do that in each of the emblem-*.svg if that's all that is needed, and is easier for core devs? That seems like a really quick short term fix, so it might be worth doing, unless a few minutes investigation of the code presents an obvious solution. Actually, we've honestly never had any designs for colored badges and I don't anticipate them in the near term, so maybe supporting entities there is overkill and modifying the SVGs directly is the right course anyway. Eben Thanks Gary! (For the mockups, that is; I'm not volunteering you for the above task). Hey, no problem, I've been volunteered for far worse things ;-) Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Accessing external media from within an activity (was: Re: Problem listing journal objects)
On Wed, Aug 26, 2009 at 11:35 AM, Gary C Marting...@garycmartin.com wrote: Hi Eben, On 26 Aug 2009, at 14:53, Eben Eliason wrote: On Wed, Aug 19, 2009 at 5:43 AM, Sascha Silbesascha-ml-ui-sugar-de...@silbe.org wrote: On Wed, Aug 19, 2009 at 08:41:28AM +0200, Tomeu Vizoso wrote: The public API is the POSIX one, though I don't know how this will be affected by future versions of Rainbow. I can't find anything regarding mount points in POSIX 2001. How do you expect Jims activity to discover them? Two ways come to my mind: a) parse /proc/mounts periodically Linux-only, time-wasting but future-proof b) use what the Journal is using internally, i.e. the Gnome way of the day cross-platform (as much as Gnome/Sugar are), event-driven, but likely to break on next release Just as a reminder: The intended workflow for Jims activity seems to be: 1. Start activity 2. Plug in USB stick with photos 3. Select and/or manage(?) photo from within the activity Answering use POSIX is like use a computer, it doesn't help getting the job done. If the answer is we want the user to copy the photos to the data store first, that doesn't get the job done either, but it's a policy and can be catered for (i.e. documented). The way I saw this working would be to extend the object chooser to allow multiple sources, including external media. Where there is currently a Journal icon in the chooser, we would also show any USB sticks and SD cards present, and these would be selectable (with the Journal the default, of course). Any activity could then invoke the object chooser to select objects from the Journal or from external media, without the overhead of building their own UI. Once the objects are loaded into the activity, they can be bundled up and saved as desired. We even have some preliminary design sketches for this feature: http://wiki.sugarlabs.org/go/Design_Team/Designs/Object_Chooser#04 You really do need to upgrade ;-p I know! I've been waiting to figure out how to get the latest releases flashed onto my XOs. The last time I looked I didn't see clear instructions for doing so. Any pointers? It's implemented and displays the content of external media (see attached image). You can even eject and insert new sticks all from within the ObjectChooser while you hunt about for that stick with those embarrassing Nice! holiday photos on. But before you get too excited, I'm not having much luck actually opening any files displayed from an external USB stick, (though I am running sugar-jhbuild that seems to be a 'between releases' hybrid just at this point in time). I've filed ticket http://dev.sugarlabs.org/ticket/1241 Eben: While I've got you here, can you confirm or deny that the icon being used to represent the Journal data-store is wrong. Note that for a release or so (~0.84 I think) the icon being shown here (ObjectChooser) and in the toolbar at the bottom of the Journal is an XO icon – it used to be the Journal icon (aka, note pad/book). I'm not convinced this change was intentional. No, I don't believe it was intentional. We should reinforce the identity of the Journal as strongly as we can. Thanks for pointing it out. Eben Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Accessing external media from within an activity (was: Re: Problem listing journal objects)
I think I'm looking in the right place, but the info isn't as readily available as I'd hoped. I'm looking here: http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Installation/OLPC In particular, I'm looking at options 2 and 3. The third says it's not yet supported. The second says it's not fully supported (though recent builds are better; perhaps the limitations listed there should be removed if it's working with new builds...), and simply links to several mailing list threads. I did read these in the past, and in general it was more digging than I was really into doing at the time, and required following several intertwined discussions about not only installing to NAND, but also running off a USB stick. Moreover, there are some download links within the mailing list posts, but those (as far as I could tell) were for older versions, and there's no clear indication that I can get the latest or exactly what to do with it on the wiki itself. In fact, it's odd to me that after clicking Get Sugar and finding my desired platform, there was no direct download link at all. Now, I don't want this to sound like I'm complaining. I think that the Get Sugar link is easy enough to find, but it wouldn't hurt to have a much bigger one somewhere in the main page. There is a big link to SoaS (which also has nice direct download instructions), and perhaps that's the most common way people will install it and that's the reason for not making the Get Sugar page more prominent. In any case, the Get Sugar page, listing the various platforms is great! It's very clear. It's the content on the specific platform page (in my case, OLPC-XO) that left me unclear on exactly how to proceed. Eben On Wed, Aug 26, 2009 at 11:55 AM, Martin Denglermar...@martindengler.com wrote: On Wed, Aug 26, 2009 at 11:43:54AM -0400, Eben Eliason wrote: On Wed, Aug 26, 2009 at 11:35 AM, Gary C Marting...@garycmartin.com wrote: You really do need to upgrade ;-p I know! I've been waiting to figure out how to get the latest releases flashed onto my XOs. The last time I looked I didn't see clear instructions for doing so. Any pointers? Where did you look? It'd be useful to know so interested people like me could fix that lack. Regards, --Gary Eben Martin ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] UI mockups
Actually, the mockup is incomplete. The gray fills are meant to represent actual images that I simply didn't have time to add to the mockup. Any entry without a preview at all was intended to have a light outline, with its activity icon shown within it instead. http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#10 Eben On Sun, Aug 23, 2009 at 10:38 AM, Gary C Marting...@garycmartin.com wrote: On 23 Aug 2009, at 12:34, Simon Schampijer wrote: On 08/22/2009 09:30 PM, Aleksey Lim wrote: On Sat, Aug 22, 2009 at 08:16:38PM +0100, Gary C Martin wrote: On 22 Aug 2009, at 19:50, Aleksey Lim wrote: On Sat, Aug 22, 2009 at 02:05:03PM +, Aleksey Lim wrote: On Wed, Aug 19, 2009 at 05:12:34PM +0200, Simon Schampijer wrote: [forwarded from christian] Hi all, I've attached two (annotated) PDFs with mockups of the issues we talked about on Sunday. The first has several options for the Journal, exploring various toolbars, the grid view, and tagging; the second looks at simple vs. complex toolbars in activities. Make sure you read the annotations, and let me know what you think. Once we have reached a consensus, I can generate PNGs and post to the wiki. Christian PS. Let's also figure out a time to chat, unless email seems sufficient. I can be available for a short time around 10am (EST)/2pm (UTC) tomorrow morning, if necessary. [1] http://shell.sugarlabs.org/~erikos/090818_journal_thumbnails.pdf [2] http://shell.sugarlabs.org/~erikos/090818_toolbars.pdf You can try Thumbs view implementation from cloned repo[3] or see screenshot[4]. In comparing with mockups it has lack of multi selection and sorting features, I heard that we are not in consensus on that(?) * using check boxes of Shift key to multi select * using title like buttons[5] or something else Also I moved details button from cell bottom to the left. [3] http://git.sugarlabs.org/projects/sugar/repos/thumbs [4] http://wiki.sugarlabs.org/go/File:Thumbs.png [5] http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#10 I've encountered another problem - I can't get rid of popups in thumbs view, since all workspace belongs to thumbs. I think we can do not auto popup palette and open them only on right click. What is it like if just the thumb image rectangle has the auto pop-up? Thats it, only thumb rectangle is sensitive but even in that case auto popups could be annoying. To me, the delay for the palette looks good enough to prevent accidental popups. I have attached a screenshot where some of the thumbnails have no border and therefore the shape of the thumb can not be distinguished that well. Maybe we should add a little black border by default? FWIW, Eben used a light grey fill in his design for empty thumbs, not sure if there was a specific decision behind that. Just did a quick mock-up with light grey fills vs. outlines, and they both seem to work well (though the fill is perhaps a little stronger). Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Yet more feedback from Boston! - Chat and Speak
On Sat, Aug 15, 2009 at 1:35 PM, Gary C Marting...@garycmartin.com wrote:
On 14 Aug 2009, at 17:11, Eben Eliason wrote:
On Thu, Aug 13, 2009 at 8:28 PM, Caroline
Meekscarol...@solutiongrove.com wrote:
Neither wind nor rain nor flaming emails will deter me from telling you
about what happened with kids and Sugar today in Boston! You however are
free to use your delete key at any time.
Today, working with 6th grade students at the Museum of Science Computer
Clubhouse I learned not to start a Sugar intro session with chat. It was
hard for us to believe but the kids spent 3 hours really wanting to do
nothing but use chat to talk to other kids in the same room!! We did get
them to use other things but
next time I will end with Chat, not start with it :)
We used both Chat and Speak. Chat was more robust.
I suggest that Speak be limited to about 4 participants. It seemed die a
lot and if someone typed a lot of garbdy gook it would try to say it all and
get behind. What do other people think of this idea? Should I ticket it?
I started the lesson by creating a chat, sharing it and showing the
students
how to join from their neighborhood. That worked fairly well.
However, some of the students wanted to create a private chat. It could
be
done but it was very challenging workflow. The problem is if two kids
decide they want to chat the natural thing for them to do is both goto
Home
and click on Chat and share that with the neighborhood. This results in
two
chats and much confusion. I don't know how to solve this, as I'm not
gifted
at UI design, but its clearly a problem. Perhaps when you start chat you
have a UI inside of chat that lets you join other existing chats
directly.
I think there are a few first-steps to simplify this process that have
already been designed. First and foremost, it should be possible to
select a sharing scope when starting a new activity. In past mockups,
we offered this functionality via a Start with option, which
revealed a submenu containing both a list of friends, and a list of
groups. We could build the first part of this today.
Likewise, the redesign of the sharing controls within the activity
itself provide us the chance to do the same when sharing an ongoing
activity. In addition to listing private and my neighborhood, we
could also introduce my friends, as well as individuals.
Ooohhh, nice one, +1, though I think the actual menu needs some thinking
about so we don't conflate the Journal Resume with - activity and this
proposed home view Start with - Friend. Also think Start with -
Good point. Perhaps resuming should say Resume in instead, to
indicate that you're entering into a new activity context.
Neighbourhood should be in that list. There is also the issue of shared
Oh, absolutely. In my mind, My Neighborhood and My friends should
act like two implicit groups. I think the best way to order the
submenu is [my neighborhood, my friends, {list of groups}, {list of
friends}].
activity titles... Currently you have to title your activity before sharing
(though that even feature seems somewhat buggy, not sure if this is broken
Sugar UI, or an issue with Telepathy), otherwise you just get default Chat
Activity activities in the neighbourhood.
There have been a number of discussions and ideas around better
default names for activity titles. Perhaps we could take a small step
with a potentially large payoff and make the default activity title
name's activity activity instead, so that at least we'd have
Eben's chat activity and Gary's chat activity, which is far more
useful as a default.
Tthere is at least one obvious string change to be made to the home activity
palettes. Start should be New, or given above possible feature perhaps
Start new is better, so that Start new with - Friend will read a
little better:
I like keeping the distinction between start and resume, both of
which are verbs. That's important. If we fel the need to make it more
explicit by appending new, that could work, but I'm not sure it's
necessary with the proper uncolored icon.
Eben
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design meeting tomorrow?
Thanks Christian, and sorry all! I would have spoken up sooner, but my vacation plans have been somewhat undefined and only today did I know exactly what time I'd be available. I'm looking forward to chatting with everyone tomorrow. Eben On Sat, Aug 15, 2009 at 9:23 PM, Christian Schmidtschm...@pentagram.com wrote: Hi again Eben has to leave at 10:30 EST tomorrow, so why don't we start 30 mins earlier, at 9:30 EST/3:30 UTC. Hopefully that works for everyone. Thanks, Christian From: Gary C Martin [mailto:g...@garycmartin.com] To: Christian Schmidt [mailto:schm...@pentagram.com], Daniel Drake [mailto:d...@laptop.org] Cc: Simon Schampijer [mailto:si...@schampijer.de], Sugar-dev Devel [mailto:sugar-de...@lists.sugarlabs.org], Eben Eliason [mailto:eben.elia...@gmail.com] Sent: Sat, 15 Aug 2009 18:42:09 -0400 Subject: Re: Design meeting tomorrow? Hi Christian, Looking at your To/Cc list, I think we're all in for the meeting, excepting I haven't seen a confirmation email from Daniel yet. Given the feature freeze is on Thursday, we should cover what we can, as soon as we can, and obviously pick up any additional feedback before the feature freeze if we can. Regards, --Gary On 15 Aug 2009, at 22:58, Christian Schmidt wrote: Hi everyone I suggested earlier this week that we meet via IRC (#sugar-meeting) at 10am EST (2pm UTC) tomorrow to discuss the new toolbars and several other current issues before the next feature freeze. Are we still on for this? There are a few people I haven't heard back from yet. We can also move it to another time during the week if tomorrow doesn't work for everyone. Thanks, Christian ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity toolbar redesign: What to do with 'simple' activities?
Last we discussed this, I think we decided that activities which don't modify the toolbars in any way should have a single toolbar containing all of the activity toolbar controls: title entry, sharing, keep, etc. Only if the activity wanted to modify the toolbars would the activity specific stuff be moved under a toolbar button. I recall coming to the same conclusion with Christian as well. Eben On Wed, Aug 12, 2009 at 7:19 AM, Lucian Branesculucian.brane...@gmail.com wrote: Would it be possible to offer a more compact design, with a single bar, but with the new API? 2009/8/12 Simon Schampijer si...@schampijer.de: Hi, I just ported the hello world example to the new toolbar design [1]. I remember that once Gary pointed out, that simple activities will look 'empty' when we move them to the new design (screenshot attached), Chat would be a famous case. Most of the activities does have options, though. How do we go forward with that? Live with that compromise? Other ideas? Thanks, Simon [1] http://git.sugarlabs.org/projects/hello-world/repos/mainline/blobs/master/activity.py#line36 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity toolbar redesign: What to do with 'simple' activities?
I would be willing to set some time aside for that. Early mornings are best for me. Eben On Wed, Aug 12, 2009 at 9:24 AM, Christian Marc Schmidtchristianm...@gmail.com wrote: Yes, I agree. Unless everyone is on the same page, it may make sense to schedule a meeting this weekend, also to go over proposals for list view in Neighborhood and to discuss groups. What does everyone think? Christian On Wed, Aug 12, 2009 at 9:15 AM, Eben Eliason eben.elia...@gmail.com wrote: Last we discussed this, I think we decided that activities which don't modify the toolbars in any way should have a single toolbar containing all of the activity toolbar controls: title entry, sharing, keep, etc. Only if the activity wanted to modify the toolbars would the activity specific stuff be moved under a toolbar button. I recall coming to the same conclusion with Christian as well. Eben On Wed, Aug 12, 2009 at 7:19 AM, Lucian Branesculucian.brane...@gmail.com wrote: Would it be possible to offer a more compact design, with a single bar, but with the new API? 2009/8/12 Simon Schampijer si...@schampijer.de: Hi, I just ported the hello world example to the new toolbar design [1]. I remember that once Gary pointed out, that simple activities will look 'empty' when we move them to the new design (screenshot attached), Chat would be a famous case. Most of the activities does have options, though. How do we go forward with that? Live with that compromise? Other ideas? Thanks, Simon [1] http://git.sugarlabs.org/projects/hello-world/repos/mainline/blobs/master/activity.py#line36 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- anyth...@christianmarcschmidt.com http://www.christianmarcschmidt.com 917/ 575 0013 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Share button in the activity toolbar (from the toolbar redesign thread)
On Tue, Aug 11, 2009 at 9:19 AM, Aleksey Limalsr...@member.fsf.org wrote: On Tue, Aug 11, 2009 at 08:02:10AM -0400, Walter Bender wrote: On Tue, Aug 11, 2009 at 6:49 AM, Simon Schampijersi...@schampijer.de wrote: On 08/06/2009 04:59 PM, Simon Schampijer wrote: On 08/06/2009 03:37 PM, Eben Eliason wrote: On Thu, Aug 6, 2009 at 6:56 AM, Simon Schampijersi...@schampijer.de wrote: On 07/31/2009 05:14 PM, Eben Eliason wrote: On Fri, Jul 31, 2009 at 8:41 AM, Aleksey Limalsr...@member.fsf.org wrote: On Fri, Jul 31, 2009 at 02:05:48PM +0200, Tomeu Vizoso wrote: On Fri, Jul 31, 2009 at 13:47, Simon Schampijersi...@schampijer.de wrote: Another question that came up today: Should the activity toolbar contain the share option by default? Disabled by default? Maybe we could use the max_participants property to know when to disable the button? This makes sense to me. I think it's useful to keep it in view to indicate that the activity is private. A non-collaborative activity still has a sharing scope. So, the question is - what is default value for max_participants :) In current code it equals to 0 but old sharing component compares it with 1 thus share combo is visible by default. An activity that supports 0 participants (or fewer!) sounds pretty useless. Clearly 1 is the logical default for this property. btw all activities, I've seen before that don't want sharing, hide share combo by share.props.visible not by max_participants, I guess it signalizes about not consistency of current implementation where user can hide/show share button by two different methods. Yup, we should push towards consistency here. I'd bet activities wouldn't bother to hide it if Sugar made it insensitive properly. Eben So, sounds like max-participants should be set to '1' by default. And we use Definitely. this value to display the sharing option or not. Or did you mean to display it and make it sensitive/insensitive, Eben? I think it should always be shown, but made insensitive accordingly based on max_participants. Eben Sounds good to me. Thanks for following up, Simon There had been some discussions on the max_participants property in the last days. What we agree on is that the share_button should be made insensitive when the activity does not provide that functionality. The API at the moment let's you set max_participants to 1, or just use sensitive property of the button and set it to false. The max_participants property makes sense, when we have more things that need to change in the UI accordingly, not only the share button. For example, the invite option in the neighborhood view. Though the shell can not access that property neither. An option would be to move this property to the activity.info. And to give the max_properties a real meaning, we would have to know how many participants are currently in that activity. To grey it out in the mesh view, when not more people can join or similar. This request would need to be made to the PS, not sure if there exist such an option. All in all I wonder if this would be a needed functionality for 0.86, or if we should better invest in making collaboration more stable. Comments appreciated, Simon Somewhat tangential, but I don't actually know what the upper bound for my activities are. It so much depends on how they are being used and what the network is like they are being used on... For example, I had no problem sharing Turtle Art among 25+ students on a wired network when they were all essentially using it to get a copy of a project from the teacher. As soon as they all started making modifications, all hell broke out. So my long-winded point is, max_participants is a really fuzzy concept. (I suppose in the case of Turtle Art, I should restrict modifications to a max_partiicipants, but let how every many people who want to copy (or watch) the action. +1 I suspect that exact value for max_participants won't be so popular and will be useful only in special cases(e.g. chess), so I'm not sure we That's true, but fuzzy numbers (let's call it an upper bound) could still be marginally useful. should add so complex logic(which should cover both sides, server and all possible clients). Activities that restrict number of playable participants could do it on theirs own like add spectator mode or on opening shared instance send Actually, it would be my desire that the shell would handle watching generally for all activities, and that's one of the reasons that having this exposed is important. It's also nice to be able to either prevent others from joining, or change join to watch accordingly. If choosing a static number is problematic, perhaps we can make it a method the shell calls on the activity while running instead. In fact, maybe it doesn't return a number, but instead a boolean indicating whether
Re: [Sugar-devel] [Design] Ad-hoc networks - New Icons
On Tue, Aug 11, 2009 at 6:21 AM, Simon Schampijersi...@schampijer.de wrote: On 08/11/2009 11:50 AM, Daniel Drake wrote: 2009/8/11 Simon Schampijersi...@schampijer.de: I think it would help, to have a new icon for the ad-hoc network to distinguish them. Could be a badged wireless network one? Or is the mesh icon appropriate? Or something completely new? I think new icons would be best, to distinguish from the mesh. I think we can expect mesh support again soon ;) From the user POV they are the same I guess. A local network, that does not need any infrastructure. Though, the mesh on the XO is handled automatically, the ad-hoc network requires user interaction to create it. I wonder if we ever will see a user using both (not at the same time) on the same machine. To think about the visual clash, at least. Perhaps we could use the mesh icon with a little XO badge, to indicate that it's functionally similar to the real mesh, but enabled by a specific XO. Thinking about this now, it might be the case that Tomeu had built this functionality as an extension of the wireless network device in the Frame; Should it be an extension of the mesh device instead, based on its perceived similarities to that feature more than an AP? Eben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Design] Ad-hoc networks - New Icons
On Tue, Aug 11, 2009 at 11:22 AM, Simon Schampijersi...@schampijer.de wrote: On 08/11/2009 03:49 PM, Eben Eliason wrote: On Tue, Aug 11, 2009 at 6:21 AM, Simon Schampijersi...@schampijer.de wrote: On 08/11/2009 11:50 AM, Daniel Drake wrote: 2009/8/11 Simon Schampijersi...@schampijer.de: I think it would help, to have a new icon for the ad-hoc network to distinguish them. Could be a badged wireless network one? Or is the mesh icon appropriate? Or something completely new? I think new icons would be best, to distinguish from the mesh. I think we can expect mesh support again soon ;) From the user POV they are the same I guess. A local network, that does not need any infrastructure. Though, the mesh on the XO is handled automatically, the ad-hoc network requires user interaction to create it. I wonder if we ever will see a user using both (not at the same time) on the same machine. To think about the visual clash, at least. Perhaps we could use the mesh icon with a little XO badge, to indicate that it's functionally similar to the real mesh, but enabled by a specific XO. Thinking about this now, it might be the case that Tomeu had built this functionality as an extension of the wireless network device in the Frame; Should it be an extension of the mesh device instead, based on its perceived similarities to that feature more than an AP? Eben Yes, as of today, it is an extension of the wireless network frame device. http://1.bp.blogspot.com/_OoKpv4QinxI/SiFiDO2RsAI/ACU/go8n8S6rrE0/s1600-h/soas-create.png From the similarities, I agree, a badged mesh icon would work well to demonstrate that. I suppose I see arguments in both directions. A badged AP icon would also make sense. Ben's question about the persistence of the network in the absence of the creator is also important to answer. Another question is the behavior: Gary and some others were wondering if we should fallback to an adhoc network automatically, if we are not connected to an AP. This might bias us towards treating it more or less like the mesh. For what it's worth, it seems like the ability for separate classes (for instance) to create separate networks would be a benefit in terms of network reliability. Eben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design help needed for web applications within Sugar
On Tue, Aug 11, 2009 at 1:13 PM, Lucian Branesculucian.brane...@gmail.com wrote: 2009/8/11 Simon Schampijer si...@schampijer.de: On 08/11/2009 12:14 PM, Lucian Branescu wrote: In fact, there is the option to install the SSB activity as well, http://dl.getdropbox.com/u/317039/create%20ssb.png Yes seen that. rgs on IRC suggested that the 'Keep in Journal' button could either save an offline version by itself or there could be a drop down with several options. Do you mean the activity keep button? Like the one in Write - where we have the options to save a richt text format or others? If yes - yeah that sounds like a good option actually. I'll go ahead and try to implement that, then. About modifying SSBs, right now all the tools for modification are inside the actul activity. I'd like to see modification of userscripts and userstyles done in 'View Source' (as well). Oh, yeah view source. Sounds interesting to me, too. We just need to make sure to not overload it. I mean editing text is easy. When it comes to changing the icon it gets more complicated, though. Perhaps the Sugar shell should allow users to change activity icons? It's an unfortunate fact that there is no activity suitable for creating SVG icons for Sugar. We need a Draw activity to fill this gap and compliment Paint... In any case, View Source already has Document view and Bundle view. We could either expand Document view to have a TreeView on the left like Bundle view or create a separate Editables view. I hesitate to overload the view source mechanism this way, actually. Should we instead be providing a seamless mechanism for modifying code, icons, etc. with other activities, so that users (eventually) have choices regarding their editors? View source is a logical step in the process, so we should certainly expose the ability to launch into editing from there, of course. I suppose an alternative argument can be made for the level of integration we could provide when editing within the view source dialog. If we could hook it up to have real-time effect on the running activity, so that making a change couldbe tested right away, that may make it worth doing... Eben Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] multiple activity versions installed simultaneously (was Re: [Bugs] #1042 UNSP: cannot install new activity version)
On Mon, Aug 10, 2009 at 11:52 AM, Benjamin M. Schwartzbmsch...@fas.harvard.edu wrote: Martin Dengler wrote: On Mon, Aug 10, 2009 at 09:26:58PM +0545, Daniel Drake wrote: 2009/8/10 Tomeu Vizoso to...@sugarlabs.org: Hi, any opinions on this? I dislike the idea of having multiple versions installed at once. The argument I saw for this case was that different versions might have incompatibilities in their collaboration protocols. Are there other reasons? Learner-generated activity patches, perhaps? Like, we're under a tree and here's my patched Terminal/Pippy/Speak that you may want to try but not commit to blowing-away your official version... I agree... and this is why we need to have real activity versioning support. The plan has always been to piggyback activity multiversion support on top of the datastore's versioning capabilities, and until that has landed, in my view, there's not much we can do. I think I agree with both Ben and Tomeu, here. Supporting multiple activity versions is crucial to allowing kids to modify activities, or create their own. At the same time, I also believe that a new owner (as in the example of modifying the Speak activity under a tree) should result in a new activity thread. That is, the resulting activity would actually be version one of (potentially) many. For this reason, encouraging a name change when ownership changes might be apropos. Eben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Share button in the activity toolbar (from the toolbar redesign thread)
On Thu, Aug 6, 2009 at 6:56 AM, Simon Schampijersi...@schampijer.de wrote: On 07/31/2009 05:14 PM, Eben Eliason wrote: On Fri, Jul 31, 2009 at 8:41 AM, Aleksey Limalsr...@member.fsf.org wrote: On Fri, Jul 31, 2009 at 02:05:48PM +0200, Tomeu Vizoso wrote: On Fri, Jul 31, 2009 at 13:47, Simon Schampijersi...@schampijer.de wrote: Another question that came up today: Should the activity toolbar contain the share option by default? Disabled by default? Maybe we could use the max_participants property to know when to disable the button? This makes sense to me. I think it's useful to keep it in view to indicate that the activity is private. A non-collaborative activity still has a sharing scope. So, the question is - what is default value for max_participants :) In current code it equals to 0 but old sharing component compares it with 1 thus share combo is visible by default. An activity that supports 0 participants (or fewer!) sounds pretty useless. Clearly 1 is the logical default for this property. btw all activities, I've seen before that don't want sharing, hide share combo by share.props.visible not by max_participants, I guess it signalizes about not consistency of current implementation where user can hide/show share button by two different methods. Yup, we should push towards consistency here. I'd bet activities wouldn't bother to hide it if Sugar made it insensitive properly. Eben So, sounds like max-participants should be set to '1' by default. And we use Definitely. this value to display the sharing option or not. Or did you mean to display it and make it sensitive/insensitive, Eben? I think it should always be shown, but made insensitive accordingly based on max_participants. Eben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] buddy tags
On Tue, Aug 4, 2009 at 7:44 AM, Gary C Marting...@garycmartin.com wrote: On 4 Aug 2009, at 04:54, Eben Eliason wrote: On Mon, Aug 3, 2009 at 10:16 PM, Gary C Marting...@garycmartin.com wrote: Hi Eben, On 4 Aug 2009, at 02:19, Eben Eliason wrote: On Mon, Aug 3, 2009 at 3:39 PM, Gary C Marting...@garycmartin.com wrote: On 2 Aug 2009, at 15:00, Tomeu Vizoso wrote: Hi Gary (and others), what was decided about buddy tagging? No one else has commented yet :-( I had a brief conversation with Christian about this recently. He said he'd try to catch up on the thread and maybe give a few comments. Fab, that would be great! Were you interested in working on it? Yes, I've just added some new mock-ups (keeping them as simple/achievable as possible), so maybe someone else can take a look at them and provide some feedback: http://wiki.sugarlabs.org/go/Design_Team/Proposals/Buddy_Tags I think the settings panel looks like a good start. I wonder if we should stick with tags here, or if it would be worth calling this a description or things I like or something similar. Yea, I was playing safe with the input box name. I wanted to avoid suggesting folks type in a natural language sentence or paragraph. If we had tokenised text field support, life here would be easier (and else where we want folks to use tags) ;-) http://wiki.sugarlabs.org/go/Human_Interface_Guidelines/The_Sugar_Interface#Tokenized_Text_Fields The palette, on the other hand, doesn't work as you've mocked it up. The primary palette is a fixed height, and only supports single line primary and secondary titles. I think the tags/description belong in the secondary palette instead. See [http://wiki.sugarlabs.org/go/Design_Team/Designs/Activity_Management#03] for a related sketch. We've abandoned the gray background, and we don't have avatars or structured content as shown here, but I think we could add a section to the secondary palette containing this extra info. It would expand, but the primary palette would always be a fixed size. Thanks. I didn't know that. I will amend my mock-ups, should work just as well with that change. It might also be nice to have the ability to have a button in one's own palette that links directly to the about me section of settings to change the info. This will also improve discoverability. The ability to open the settings to a specific section (and even anchored subsection, perhaps) is something we've wanted to expose in many places. It might be a nice task for someone looking for a nice self-contained feature to build. On the fence about this one, I find one's own palette is getting a little to long already (My Settings, Logout, Restart, Shutdown, Register). Ugh! Register really needs to be dealt with; the fact that it ever entered this menu is frustrating, and it is another long-standing temporary hack that never got fixed. The intended solution for this particluar feature is to represent school servers in the neighborhood; The Register action is supposed to be performed on the server, not on you. +1 that would be great. Isn't My settings just About me in disguise? Maybe we should just change that string. There's no need to have the same button appear twice in the palette So just a string change, you'd still end up at the top level of the control panel, right? Oh, no! My mistake. I was thinking that the XO would be an appropriate place to expose a direct link to the About me settings. I wasn't thinking clearly, and forgot that this was the only way into settings in general. The suggestion to have a computer device in the frame could fix that... I suppose there's no ridding of 'Logout, Restart, and Shutdown. =) Hmmm, random thought. Should clicking on your buddy icon open My Settings as the default operation? Right now it's just a pretty picture with a palette hanging off it. That way you'd just click your buddy icon and pick About Me, avoiding all those nasty techie strings. That's an interesting idea, though if the button is in the palette, that might be enough. I might instead suggest as a global rule that clicking on a buddy should reveal the (full) palette by default. Might that conflate left click vs. right click behaviour? But, other than that, yes this is a fair call I think, and resolves the issue (safely) of what would be the default action when clicking on some other buddy icon. Perhaps the general rule clicking icons with no default action should reveal full palette can be used else where (e.g. battery device frame icon, network device frame icon). That's always been the intended behavior for buttons without actions, actually. I've informally referred to them as palette buttons (akin to toolbar buttons), as their purpose is simply to reveal the corresponding palette. I do see the problem with conflating right/left clicks, though. The same would be true for eg. speaker vs. battery, where the former has
Re: [Sugar-devel] buddy tags
On Tue, Aug 4, 2009 at 8:21 PM, Gary C Marting...@garycmartin.com wrote: On 4 Aug 2009, at 03:16, Gary C Martin wrote: The palette, on the other hand, doesn't work as you've mocked it up. The primary palette is a fixed height, and only supports single line primary and secondary titles. I think the tags/description belong in the secondary palette instead. See [http://wiki.sugarlabs.org/go/Design_Team/Designs/Activity_Management#03 ] for a related sketch. We've abandoned the gray background, and we don't have avatars or structured content as shown here, but I think we could add a section to the secondary palette containing this extra info. It would expand, but the primary palette would always be a fixed size. Thanks. I didn't know that. I will amend my mock-ups, should work just as well with that change. Mock-ups amended, they now show self tags in the secondary palette area: http://wiki.sugarlabs.org/go/Design_Team/Proposals/Buddy_Tags Looks good. The more I look at it, the more I think we need to come up with a good label for this. I keep coming back to the simple but appropriate likes idea. In the settings, we could label the field I like:, and in buddy palettes we could have a label Gary likes: which would provide some context for the list. It's also nice because this short and intuitive label seems to imply a list format, to some extent. We should also consider a limit on the entry field, or a way to limit the amount shown in the palette (probably just an ellipsis). Eben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] buddy tags
On Tue, Aug 4, 2009 at 8:36 PM, Benjamin M. Schwartzbmsch...@fas.harvard.edu wrote: Gary C Martin wrote: Mock-ups amended, they now show self tags in the secondary palette area: http://wiki.sugarlabs.org/go/Design_Team/Proposals/Buddy_Tags Why are we calling this section tags? When I look at these mockups, I see a perfect illustration of a buddy profile [1], like an AIM profile or away message. Specifically, the mockups appear to preserve the entire string, and not merely provide an unordered set of space-delimited strings. I think this is a feature. All you need to do is change the label on the entry field from Tags to Profile, and let the search field be a full-text search in the profiles. Users can use their profiles as tags, or however they want. Agreed. I see no reason to enforce a space/comma separated list. I still kind of like likes as the prompt, but something more general like profile could also work. Eben If you want to add tag-specific features like machine-readable tags, internationalization, etc., that's fine... but I would make that an additional, separate entity from the more flexible Profile. [1] http://dev.laptop.org/ticket/6686 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Erase in the Ring and less hot hot corners
On Mon, Aug 3, 2009 at 8:37 PM, Gary C Marting...@garycmartin.com wrote: On 4 Aug 2009, at 00:26, Caroline Meeks wrote: +1 to taking erase out of the activity ring. We need to keep that view as simple as possible for the youngest children. Moving the mouse is a challenge for the youngest kids, fewer targets with less that can go wrong is a big win. Sounds fine to me. Filed: http://dev.sugarlabs.org/ticket/1128 I think I'm also a +1 on the less hot hot corners. I definitely see issues with getting the frame unintentionally. But that seems like a choice with more tradeoffs. Can we hold off the Frame wars for just now ;-) =) We could, perhaps, agree to increase the default delay for corner activation, since this is configurable in settings. Alternatively, this should be configurable for specific distributions, I believe. I've always been comfortable with about .25 seconds, but perhaps those who work with kids will have a better idea, given their motor skills, what a reasonable delay might be. I wouldn't go much beyond .5 seconds, in any case, since discoverability is still important. Eben Regards, --Gary On Mon, Aug 3, 2009 at 7:13 PM, James Cameron qu...@laptop.org wrote: On Tue, Aug 04, 2009 at 01:22:35AM +0545, Christoph Derndorfer wrote: e.g. here in Nepal they [...] removed the 'Remove' option from the activities menu in Home View (so activities can only be truly removed from the List View). I confirm that with the children I test on, using OLPC build 802, they lose activities from the ring as a result of accidental mouse movements. After a few hours though they don't do it. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Share button in the activity toolbar (from the toolbar redesign thread)
On Fri, Jul 31, 2009 at 8:41 AM, Aleksey Limalsr...@member.fsf.org wrote: On Fri, Jul 31, 2009 at 02:05:48PM +0200, Tomeu Vizoso wrote: On Fri, Jul 31, 2009 at 13:47, Simon Schampijersi...@schampijer.de wrote: Another question that came up today: Should the activity toolbar contain the share option by default? Disabled by default? Maybe we could use the max_participants property to know when to disable the button? This makes sense to me. I think it's useful to keep it in view to indicate that the activity is private. A non-collaborative activity still has a sharing scope. So, the question is - what is default value for max_participants :) In current code it equals to 0 but old sharing component compares it with 1 thus share combo is visible by default. An activity that supports 0 participants (or fewer!) sounds pretty useless. Clearly 1 is the logical default for this property. btw all activities, I've seen before that don't want sharing, hide share combo by share.props.visible not by max_participants, I guess it signalizes about not consistency of current implementation where user can hide/show share button by two different methods. Yup, we should push towards consistency here. I'd bet activities wouldn't bother to hide it if Sugar made it insensitive properly. Eben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Initial implementation of toolbars design
On Thu, Jul 30, 2009 at 3:46 PM, Simon Schampijersi...@schampijer.de wrote: On 07/29/2009 07:03 PM, Gary C Martin wrote: Hi Simon, On 29 Jul 2009, at 08:55, Simon Schampijer wrote: FWIW: Picking the top level tool set is going to be a real tough call in a number of cases as we loose toolbar space for each extra tab, plus the activity icon on far left (essential for Activity recognition), plus the stop icon on far right (essential, no questions, no doubts). The features that actually fit in the remaining space may seem quite an arbitrary hotchpotch. Gary, I am not sure I get your arguments right :/ Can you elaborate? What I conclude of all the answers, I think that space in the primary toolbar is an issue. So we need to decide what to put there. Does activity icon and stop icon sounds good to you as well? Sorry if that wasn't clear. Activity icon and stop icon are essential. The Activity icon is going to be critical for identifying what activity you are in at a glance, especially if the actual title name is hidden away in a sub toolbar. A downside if we loose the title in the primary toolbar is reinforcement of knowing what activity you are in (say you are copy/pasting between two similar Write documents)... Ok, thanks for the explanation. The differentiation of the running instance of two activities of the same type is a good point. But, does this happen often? I guess many kids will run one activity of each type at a time, and remember performance constraints ;p And one can use the frame to distinguish the activities. Personally, I see more the issue of naming an activity, since as said in another post I am not really convinced about the naming alert. I'll have to think about this idea more, but: we could also have the naming alert appear as a palette attached to the stop button, instead. It doesn't change the behavior too much (it requires 2 clicks to stop an activity for the first time if it hasn't been named), but the use of the palette might feel more consistent with Sugar in general. On the other hand, it could be strange to change the behavior of the stop button between the first and other cases. One little thing I am a bit worried about, is that we miss labels for the sub-toolbars. I hope the icons are meaningful enough for the users - but then labels can be misleading as well, and many of our users can't possibly read. Yes, we had some thoughts. We'll hash it out some more. About alignment (attached is a snapshot), should we align the 'share button' and the 'keep one' to the left that the way to get to this button is not so long, when revealing the toolbar? I think we should be thinking about this in the general case. Sometimes one will need to reach the other end to reach controls (and (though not for the activity toolbar) this depends on where the toolbar button sits within the primary toolbar). We should make sure that the palette behavior works well in these instances. For instance, it shouldn't disappear immediately on mouse-leave. Perhaps the delay should be longer than for normal palettes, due to their peculiar dimensions. That said, I'd be fine with aligning these buttons to the left in this instance. Eben PS a few notes on the design: 1. Is this screenshot showing the hover state of the toolbar button with the toolbar already locked in? If not, the small arrow beneath the activity icon should still be pointed downwards, to indicate that clicking on the button will lock it into place. It should appear pointing upward only when already locked in. 2. We should fix the style for the text entry so it appears correctly on black backgrounds. 3. I'll get you those scissors tonight, for real this time. Also, can we change the arrow to match those in the mockups? The one shown here competes with the icons themselves. 4. But these are nitpicks. Fantastic work!! Thanks, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Initial implementation of toolbars design
Here are the icons we used for the view, edit, and color toolbars, Sugarized of course. If anyone has suggestions for other common toolbars across activities that deserve icons in artwork, let me know. Eben On Thu, Jul 30, 2009 at 6:02 PM, Eben Eliasone...@laptop.org wrote: On Thu, Jul 30, 2009 at 3:46 PM, Simon Schampijersi...@schampijer.de wrote: On 07/29/2009 07:03 PM, Gary C Martin wrote: Hi Simon, On 29 Jul 2009, at 08:55, Simon Schampijer wrote: FWIW: Picking the top level tool set is going to be a real tough call in a number of cases as we loose toolbar space for each extra tab, plus the activity icon on far left (essential for Activity recognition), plus the stop icon on far right (essential, no questions, no doubts). The features that actually fit in the remaining space may seem quite an arbitrary hotchpotch. Gary, I am not sure I get your arguments right :/ Can you elaborate? What I conclude of all the answers, I think that space in the primary toolbar is an issue. So we need to decide what to put there. Does activity icon and stop icon sounds good to you as well? Sorry if that wasn't clear. Activity icon and stop icon are essential. The Activity icon is going to be critical for identifying what activity you are in at a glance, especially if the actual title name is hidden away in a sub toolbar. A downside if we loose the title in the primary toolbar is reinforcement of knowing what activity you are in (say you are copy/pasting between two similar Write documents)... Ok, thanks for the explanation. The differentiation of the running instance of two activities of the same type is a good point. But, does this happen often? I guess many kids will run one activity of each type at a time, and remember performance constraints ;p And one can use the frame to distinguish the activities. Personally, I see more the issue of naming an activity, since as said in another post I am not really convinced about the naming alert. I'll have to think about this idea more, but: we could also have the naming alert appear as a palette attached to the stop button, instead. It doesn't change the behavior too much (it requires 2 clicks to stop an activity for the first time if it hasn't been named), but the use of the palette might feel more consistent with Sugar in general. On the other hand, it could be strange to change the behavior of the stop button between the first and other cases. One little thing I am a bit worried about, is that we miss labels for the sub-toolbars. I hope the icons are meaningful enough for the users - but then labels can be misleading as well, and many of our users can't possibly read. Yes, we had some thoughts. We'll hash it out some more. About alignment (attached is a snapshot), should we align the 'share button' and the 'keep one' to the left that the way to get to this button is not so long, when revealing the toolbar? I think we should be thinking about this in the general case. Sometimes one will need to reach the other end to reach controls (and (though not for the activity toolbar) this depends on where the toolbar button sits within the primary toolbar). We should make sure that the palette behavior works well in these instances. For instance, it shouldn't disappear immediately on mouse-leave. Perhaps the delay should be longer than for normal palettes, due to their peculiar dimensions. That said, I'd be fine with aligning these buttons to the left in this instance. Eben PS a few notes on the design: 1. Is this screenshot showing the hover state of the toolbar button with the toolbar already locked in? If not, the small arrow beneath the activity icon should still be pointed downwards, to indicate that clicking on the button will lock it into place. It should appear pointing upward only when already locked in. 2. We should fix the style for the text entry so it appears correctly on black backgrounds. 3. I'll get you those scissors tonight, for real this time. Also, can we change the arrow to match those in the mockups? The one shown here competes with the icons themselves. 4. But these are nitpicks. Fantastic work!! Thanks, Simon attachment: toolbar_edit.svgattachment: toolbar_view.svgattachment: toolbar_colors.svg___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Initial implementation of toolbars design
On Thu, Jul 30, 2009 at 10:07 PM, Gary C Marting...@garycmartin.com wrote: Hi Eben, On 31 Jul 2009, at 01:18, Eben Eliason wrote: Here are the icons we used for the view, edit, and color toolbars, Sugarized of course. If anyone has suggestions for other common toolbars across activities that deserve icons in artwork, let me know. Eben Share with: is one, unless you're OK with one of the ones I knocked up, though if it's on a secondary palette and primary space isn't anymore an issue, then the full text menu can stay (and make the Activity palette less empty): http://wiki.sugarlabs.org/go/File:Toolbar_mockup_gary_share_with.png http://wiki.sugarlabs.org/go/File:Toolbar_mockup_gary_share_with_v2.png I think the sharing scope should be indicated by the corresponding zoom level icons. It might be worth keeping the dropdown once we have proper group support, since the name of the group is important and not communicated by the icon itself. Eben Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Initial implementation of toolbars design
On Thu, Jul 30, 2009 at 10:28 PM, Aleksey Limalsr...@member.fsf.org wrote: On Thu, Jul 30, 2009 at 06:02:00PM -0400, Eben Eliason wrote: On Thu, Jul 30, 2009 at 3:46 PM, Simon Schampijersi...@schampijer.de wrote: On 07/29/2009 07:03 PM, Gary C Martin wrote: Hi Simon, On 29 Jul 2009, at 08:55, Simon Schampijer wrote: FWIW: Picking the top level tool set is going to be a real tough call in a number of cases as we loose toolbar space for each extra tab, plus the activity icon on far left (essential for Activity recognition), plus the stop icon on far right (essential, no questions, no doubts). The features that actually fit in the remaining space may seem quite an arbitrary hotchpotch. Gary, I am not sure I get your arguments right :/ Can you elaborate? What I conclude of all the answers, I think that space in the primary toolbar is an issue. So we need to decide what to put there. Does activity icon and stop icon sounds good to you as well? Sorry if that wasn't clear. Activity icon and stop icon are essential. The Activity icon is going to be critical for identifying what activity you are in at a glance, especially if the actual title name is hidden away in a sub toolbar. A downside if we loose the title in the primary toolbar is reinforcement of knowing what activity you are in (say you are copy/pasting between two similar Write documents)... Ok, thanks for the explanation. The differentiation of the running instance of two activities of the same type is a good point. But, does this happen often? I guess many kids will run one activity of each type at a time, and remember performance constraints ;p And one can use the frame to distinguish the activities. Personally, I see more the issue of naming an activity, since as said in another post I am not really convinced about the naming alert. I'll have to think about this idea more, but: we could also have the naming alert appear as a palette attached to the stop button, instead. It doesn't change the behavior too much (it requires 2 clicks to stop an activity for the first time if it hasn't been named), but the use of the palette might feel more consistent with Sugar in general. On the other hand, it could be strange to change the behavior of the stop button between the first and other cases. One little thing I am a bit worried about, is that we miss labels for the sub-toolbars. I hope the icons are meaningful enough for the users - but then labels can be misleading as well, and many of our users can't possibly read. Yes, we had some thoughts. We'll hash it out some more. About alignment (attached is a snapshot), should we align the 'share button' and the 'keep one' to the left that the way to get to this button is not so long, when revealing the toolbar? I think we should be thinking about this in the general case. Sometimes one will need to reach the other end to reach controls (and (though not for the activity toolbar) this depends on where the toolbar button sits within the primary toolbar). We should make sure that the palette behavior works well in these instances. For instance, it shouldn't disappear immediately on mouse-leave. Perhaps the delay should be longer than for normal palettes, due to their peculiar dimensions. That said, I'd be fine with aligning these buttons to the left in this instance. Eben PS a few notes on the design: 1. Is this screenshot showing the hover state of the toolbar button with the toolbar already locked in? Nope, in current implementation there is no way to open hover palette if toolbar is locked in OK, then the arrow should still be pointing down at this point, indicating that clicking the button will lock it in place below. Once locked in, it changes directions to point up indicating that a second click will close it. Refer to: http://wiki.sugarlabs.org/go/Design_Team/Designs/Toolbars#06 If not, the small arrow beneath the activity icon should still be pointed downwards, to indicate that clicking on the button will lock it into place. It should appear pointing upward only when already locked in. 2. We should fix the style for the text entry so it appears correctly on black backgrounds. 3. I'll get you those scissors tonight, for real this time. Also, can we change the arrow to match those in the mockups? The one shown here competes with the icons themselves. What do you mean exactly, position, size or arrows shape (in case of shape it uses paint_arrow gtk function, I guess its much straight forward to use gtk function instead of custom images e.g. using the same shape like arrows in other widgets) I'd like it to match the arrow in the mockups. In fact, I think we've intended to use this filled triangle everywhere in the UI (such as nested menus), so it would be fine to change this at the gtk level. Actually, I thought Ben B. had worked on that at one point, but I never saw
Re: [Sugar-devel] Initial implementation of toolbars design
On Thu, Jul 30, 2009 at 9:21 PM, Gary C Marting...@garycmartin.com wrote: On 30 Jul 2009, at 20:46, Simon Schampijer wrote: On 07/29/2009 07:03 PM, Gary C Martin wrote: Sorry if that wasn't clear. Activity icon and stop icon are essential. The Activity icon is going to be critical for identifying what activity you are in at a glance, especially if the actual title name is hidden away in a sub toolbar. A downside if we loose the title in the primary toolbar is reinforcement of knowing what activity you are in (say you are copy/pasting between two similar Write documents)... Ok, thanks for the explanation. The differentiation of the running instance of two activities of the same type is a good point. But, does this happen often? I guess many kids will run one activity of each type at a time, and remember performance constraints ;p And one can use the frame to distinguish the activities. OK, next nit pick (apologise as it is clearly a design oversight not implementation issue). Are we suggesting we make all the lovely, really simple, Activities (the ones who have managed to avoid tabs and just a title, keep, stop, and perhaps sharing) now show a 95% empty top bar (with just the activity icon at one end and the stop over at the other). And require popping up and potentially adjusting the canvas sizes to fit the Activity sub toolbar? Just did a very (very) quick/rough dig through. That's an interesting question. I'll have to take a look at some of these activities. I actually find it odd that so many wouldn't have any use for buttons or other controls. Perhaps a number of them are revealing these controls in the canvas below instead of using toolbars? For what it's worth, I have always found it a bit odd when activities embed their own custom controls amidst the cross-activity controls. Perhaps we could institute a rule by which the primary toolbar will BE the only toolbar (not a toolbar button) if and only if the activity adds no toolbar controls at all. If, on the other hand, the activity wants their own controls, these would appear in the primary toolbar to the right of the activity icon. Pippy (though we could finally move run and stop into the toolbar). That would be great! Maze IRC Chat Typing Turtle EToys (has title, sharing, keep, stop, and other buttons, ) Etoys has always behaved slightly differently since it's not using GTK. Most (all?) of every MaMaMedia (Slider Puzzle, Jigsaw Puzzle, Poll builder, Story builder Joke Machine, etc...) et al... Ideally I'd like to see an activity icon, and its journal title appearing, so you have the best chance of knowing 'what' you are currently looking at. OT: Activity icon followed by title makes an activity instance look like the Journal entry row it came from, which would be a good thing, but I couldn't find a reliable design for that formula. Personally, I see more the issue of naming an activity, since as said in another post I am not really convinced about the naming alert. I know what you mean. I did wonder once if a modal activity alert style pop-up, below the activity toolbar, would be less intrusive, and more in context with the activity than a pop-up dialogue that hides most of the Activity context. That's a possibility, but as a general rule those alert bars are non-modal. However, clearly any naming alert when stopping the activity must be modal, since it needs to prevent the action from taking place until the dialog is settled. One little thing I am a bit worried about, is that we miss labels for the sub-toolbars. I hope the icons are meaningful enough for the users - but then labels can be misleading as well, and many of our users can't possibly read. +1 Extremely good icons are essential or else WE FAIL and walk backwards here. :-( At least this is something we can iterate on before the 0.86 official release that gets documented and pushed out to deployments. Yup. I think providing a fairly extensive set of default icons would be a good thing, both to help activity developers out, and for consistency in the UI. I'd be happy to help out with this. It would also be nice to extend the default icon set further in general. There are lots of common icons that we should be providing, for the same reasons as above, that just never made it. I have a list, and perhaps many even designed already, somewhere. About alignment (attached is a snapshot), should we align the 'share button' and the 'keep one' to the left that the way to get to this button is not so long, when revealing the toolbar? My vote is for no right align. Put those icons (share with, keep) left aligned near any other icons (perhaps a tag feature can show here in future). My main concern here would be for a child trying to drive the mouse all the way over from the far left of the display, to the far right to hit a target. Again, this depends on the context, and where a given toolbar buttons resides within the
Re: [Sugar-devel] Initial implementation of toolbars design
On Tue, Jul 28, 2009 at 10:12 PM, Gary C Marting...@garycmartin.com wrote: On 28 Jul 2009, at 19:03, Eben Eliason wrote: On Tue, Jul 28, 2009 at 12:07 PM, Simon Schampijersi...@schampijer.de wrote: On 07/28/2009 03:48 PM, Eben Eliason wrote: On Mon, Jul 27, 2009 at 5:26 PM, Simon Schampijersi...@schampijer.de wrote: On 07/18/2009 04:17 AM, Gary C Martin wrote: Hi Caroline, On 17 Jul 2009, at 22:14, Caroline Meeks wrote: We can put it in front of actual kids once you get a sample working. We could even try playing the video for our existing classes. I don't know if they'll be able to give you feedback from just seeing the video. Might be interesting to find out. Yes that's an interesting one... I have more understanding of usability studies with literate adults, where you can have a controlled environment. With the idea that you set goals/tasks to be completed with the interface and ask the user to vocalise what they think they are doing (I'm clicking this because I think it's the search button...). You only interact with them once they are clearly stuck, to help them get back on track. Asking for any-ones opinion is usually frowned upon in usability studies, as opinion is almost always different from actual behaviour – but some opinions are better than nothing, which is why I keep asking :-) Perhaps I should work with Walter and Aleksey's initial toolbar code and make an identical test clone of TA but with the new toolbar design (I can use Aleksey's Write mock-up code as an example)? Then you could let the class (or a random selection of the class) use it for some tasks and watch how well (or not) they manage with the new interface? Simon: have you used TA yet in your lessons? Yes, the problem is, that I won't get into class before September again - we have summer holidays :/ About the design - as already noted, the current implementation does not match gary's mockups. I think the mockups are more consistent in using icons in the primary toolbar. Having the text entry field (activity name) present, could help the users that know Sugar already. They would not feel that much lost. I think that the title, sharing, keep, and other buttons (perhaps with the exception of stop, since I know many want this on the primary toolbar...) should live inside a secondary activity toolbar, in much the same way we have an activity tab now. The icon for the activity toolbar would be the activity icon itself, colored, and always placed at the far left of the primary toolbar. The primary reasons for this are 1) consistency across activities and 2) saving space in the primary toolbar for the activity itself. Hmm, giving a title could be seen as a first class action. We want the user to give a title (naming alert), so it can be found more easily in the journal. Maybe this should be in the top toolbar as well? I know this has issues space wise. It's true, but those buttons consume a lot of valuable real estate in the primary toolbar, and the user is unlikely to name or share more than once, and should never really need to keep manually. That means that about half of the ever-present controls shown aren't important for regular use of the activity. With my ActivityTeam hat on; you do realise this is the option requiring the most rework for authors and maintainers? It puts them/us back in the hot seat task for re-designing the toolbar layouts fairly extensively (at least for any non trivial cases). I'm not sure that's entirely true. I think keeping the generic activity functions all in one place, separate from the primary toolbar, makes it easiest for developers to use the primary toolbar to their greatest benefit. I don't think there needs to be any rules requiring specific feature sets to be present in the primary toolbar—some developers may well choose to place solely toolbar buttons in the primary toolbar; Others may choose to place basic controls there as appropriate. An example of the former kind might be write (or any activity with lots of tabs). Browse (and perhaps even paint), on the other hand are examples which clearly illustrate the benefits of keeping primary controls in the primary toolbar. First, it means that they are exposed up front, and second it means that they can be used in combination with other sets of secondary tools. In Browse, it remains possible to navigate the web even if you want to have edit or view controls visible. In paint, it's possible to change the drawing tool while also keeping a palette of colors available. This choice should be seen as a benefit, not a burden. But glad this is finally being discussed, it was pretty much the first feedback I was after, and Aleksey also I think – his Write toolbar test was closer to your original designs, but didn't manage to get all the buttons in ;-b FWIW: Picking the top level tool set is going to be a real tough call in a number of cases as we loose toolbar
Re: [Sugar-devel] Initial implementation of toolbars design
On Mon, Jul 27, 2009 at 5:26 PM, Simon Schampijersi...@schampijer.de wrote: On 07/18/2009 04:17 AM, Gary C Martin wrote: Hi Caroline, On 17 Jul 2009, at 22:14, Caroline Meeks wrote: We can put it in front of actual kids once you get a sample working. We could even try playing the video for our existing classes. I don't know if they'll be able to give you feedback from just seeing the video. Might be interesting to find out. Yes that's an interesting one... I have more understanding of usability studies with literate adults, where you can have a controlled environment. With the idea that you set goals/tasks to be completed with the interface and ask the user to vocalise what they think they are doing (I'm clicking this because I think it's the search button...). You only interact with them once they are clearly stuck, to help them get back on track. Asking for any-ones opinion is usually frowned upon in usability studies, as opinion is almost always different from actual behaviour – but some opinions are better than nothing, which is why I keep asking :-) Perhaps I should work with Walter and Aleksey's initial toolbar code and make an identical test clone of TA but with the new toolbar design (I can use Aleksey's Write mock-up code as an example)? Then you could let the class (or a random selection of the class) use it for some tasks and watch how well (or not) they manage with the new interface? Simon: have you used TA yet in your lessons? Yes, the problem is, that I won't get into class before September again - we have summer holidays :/ About the design - as already noted, the current implementation does not match gary's mockups. I think the mockups are more consistent in using icons in the primary toolbar. Having the text entry field (activity name) present, could help the users that know Sugar already. They would not feel that much lost. I think that the title, sharing, keep, and other buttons (perhaps with the exception of stop, since I know many want this on the primary toolbar...) should live inside a secondary activity toolbar, in much the same way we have an activity tab now. The icon for the activity toolbar would be the activity icon itself, colored, and always placed at the far left of the primary toolbar. The primary reasons for this are 1) consistency across activities and 2) saving space in the primary toolbar for the activity itself. Can we get mockups for Browse? I would do the changes then there. We have them! Browse was the first activity I worked with when working up the new toolbar designs. The activity icon I spoke of above is notable absent from my early mockups, but that shouldn't have much of an effect on things. Here they are: http://wiki.sugarlabs.org/go/Design_Team/Designs/Toolbars When doing testing we should maybe do tests for people that have used Sugar before already, and probands with no knowledge of Sugar at all. Regards, Simon Btw: I was lost a bit with that the canvas is only shifted down when the toolbar is locked. But I guess it makes sense, in order to have not shifting the canvas down when you search for an option and pulling down the different toolbars. Not sure, yet. Yes, this is by design. The theory here is that it's possible to use them like palettes, for occasional actions, without locking into place and changing the canvas. I suppose the effect could be a little strange when they become locked, but I'd suspect it would be even stranger to have the canvas constantly shifting back and forth while hovering over toolbar buttons. Eben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Initial implementation of toolbars design
On Tue, Jul 28, 2009 at 12:07 PM, Simon Schampijersi...@schampijer.de wrote: On 07/28/2009 03:48 PM, Eben Eliason wrote: On Mon, Jul 27, 2009 at 5:26 PM, Simon Schampijersi...@schampijer.de wrote: On 07/18/2009 04:17 AM, Gary C Martin wrote: Hi Caroline, On 17 Jul 2009, at 22:14, Caroline Meeks wrote: We can put it in front of actual kids once you get a sample working. We could even try playing the video for our existing classes. I don't know if they'll be able to give you feedback from just seeing the video. Might be interesting to find out. Yes that's an interesting one... I have more understanding of usability studies with literate adults, where you can have a controlled environment. With the idea that you set goals/tasks to be completed with the interface and ask the user to vocalise what they think they are doing (I'm clicking this because I think it's the search button...). You only interact with them once they are clearly stuck, to help them get back on track. Asking for any-ones opinion is usually frowned upon in usability studies, as opinion is almost always different from actual behaviour – but some opinions are better than nothing, which is why I keep asking :-) Perhaps I should work with Walter and Aleksey's initial toolbar code and make an identical test clone of TA but with the new toolbar design (I can use Aleksey's Write mock-up code as an example)? Then you could let the class (or a random selection of the class) use it for some tasks and watch how well (or not) they manage with the new interface? Simon: have you used TA yet in your lessons? Yes, the problem is, that I won't get into class before September again - we have summer holidays :/ About the design - as already noted, the current implementation does not match gary's mockups. I think the mockups are more consistent in using icons in the primary toolbar. Having the text entry field (activity name) present, could help the users that know Sugar already. They would not feel that much lost. I think that the title, sharing, keep, and other buttons (perhaps with the exception of stop, since I know many want this on the primary toolbar...) should live inside a secondary activity toolbar, in much the same way we have an activity tab now. The icon for the activity toolbar would be the activity icon itself, colored, and always placed at the far left of the primary toolbar. The primary reasons for this are 1) consistency across activities and 2) saving space in the primary toolbar for the activity itself. Hmm, giving a title could be seen as a first class action. We want the user to give a title (naming alert), so it can be found more easily in the journal. Maybe this should be in the top toolbar as well? I know this has issues space wise. It's true, but those buttons consume a lot of valuable real estate in the primary toolbar, and the user is unlikely to name or share more than once, and should never really need to keep manually. That means that about half of the ever-present controls shown aren't important for regular use of the activity. One alternative is to start activities with the activity toolbar shown beneath the primary toolbar, but again that would mostly just serve for naming. I hesitate to do this, since I'd much rather, again, allow the activity to decide if it wants a secondary toolbar to be shown by default. For instance, I think Paint should show the secondary color selector toolbar by default, so that both colors and the basic drawing tools are visible when entering the activity. (http://wiki.sugarlabs.org/go/Design_Team/Designs/Toolbars#11) I think the current naming alert behavior is probably sufficient, unless feedback indicates that it's not helping in practice. In any case, would be nice to sort this one out sooner then later. We want to push a first version on Thursday, that people can test the redesign out - ideally in class. Feature Freeze is approaching: http://wiki.sugarlabs.org/go/0.86/Roadmap#Schedule OK, time is tight! Christian any thoughts? Can we get mockups for Browse? I would do the changes then there. We have them! Browse was the first activity I worked with when working up the new toolbar designs. The activity icon I spoke of above is notable absent from my early mockups, but that shouldn't have much of an effect on things. Here they are: http://wiki.sugarlabs.org/go/Design_Team/Designs/Toolbars Ok, cool. Do you have the scissor icon already? ;p Yeah, I'll dig it up tonight when I get home. Eben When doing testing we should maybe do tests for people that have used Sugar before already, and probands with no knowledge of Sugar at all. Regards, Simon Btw: I was lost a bit with that the canvas is only shifted down when the toolbar is locked. But I guess it makes sense, in order to have not shifting the canvas down when you search for an option and pulling down the different toolbars. Not sure, yet. Yes
Re: [Sugar-devel] Book bundles and Read
On Sun, Jul 26, 2009 at 11:56 AM, Gary C Marting...@garycmartin.com wrote: Hi Aleksey, On 25 Jul 2009, at 17:02, Aleksey Lim wrote: On Sat, Jul 25, 2009 at 04:24:33PM +0100, Gary C Martin wrote: Hi Aleksey, On 25 Jul 2009, at 05:02, Aleksey Lim wrote: On Sat, Jul 25, 2009 at 04:53:33AM +0100, Gary C Martin wrote: The term content bundles is still pretty wooly for me. Are we talking zip files, perhaps with some formal structure? Object Bundles[1] will deprecate .xol in 0.86 and in case of previews, it will be regular field in METADATA file: preview_file = file-inside-bundle-with-preview [1] http://wiki.sugarlabs.org/go/Features/Object_Bundles [2] http://wiki.sugarlabs.org/go/Features/Object_Bundles#METADATA_file Thanks for the references. Having read that page I'm still confused about aspects of this proposal. Not sure I'm clear enough to ask sane questions. Let me try: 1) By composite object do you mean a container of many files/folders (a little like current .xol), or a container of many Journal compatible entries (i.e. 40 Read Activity pdf ebooks with thumbnail images, tags, and description)? Container of of many files/folders that represented by one Journal entry so, in case of library it would be: one entry in Journal which has text/html and directory with content of library(somewhere). After activating it, Browse will open one of many files/folders e.g. index.html 2) Is .xol extension proposed to go away, or will .xol be repurposed as a the composite object? In case of [1] .xol is just a subset of object bundles and sugar will still support former .xol(but they will be deprecated) 3) Why should a composite object open in Browse, is this just an example of a zipped up web site? Because Journal entry which represent composite object will have text/html mime_type, in face there is only one difference between regular Journal objects and composite - regular object has only one file but composite has directory. +1 Thanks, understood. 4) Will .xo will be used to store Activity bundles (i.e as we have now), and Activity entries (i.e. all meta-data and files as found for a Journal entry)? Activity just another example of composite object(in common sense) and I'm thinking about adding them to 0.86 as well. According to [2] there could be two forms of object bundles: * one or several packed Activity entries (they can have activity field) * the while bundle as composite object which will be represented by one Journal activity-less object (e.g. library or activity) OK, I think I understand that :-) 1) 1 (to N) Activity entries, all wrapped inside the .xo, on download to Journal they are all expanded as individual Journal entries. +1 :-) 2) A zipped folder of files/folders that is placed in the Journal as a single entry (composite object). Question: Is this equivalent to an .xol? Or, can it hold arbitrary files (i.e .xol is a subset), like a bunch of C source files? Maybe you want to make a Gcc Activity to open this composite object at some point? ;-b I've always envisioned a Bundle activity which is a glorified tar/zip/other-bundle-format viewing and creation tool. With Bundle, it would be possible to open any such file in the Journal (including activity bundles, of course) to view its contents. It would also support extracting all or part of the bundle contents to separate Journal entries, as well as creating new bundles from arbitrary collections of objects. It would even be possible to add collaboration on top of this, so groups of kids could create bundles together, aggregating entries from each of their Journals into a single product. This would be useful for group projects, for instance. I know a class took this on as a project at one point, though I never heard how that turned out. I believe this—http://activities.sugarlabs.org/en-US/sugar/addon/4079—is the result, but I haven't had a chance to try it yet. In any case, it might be nice to keep it in mind, and perhaps extend its features in line with these new discussions for object bundles if appropriate. For instance, it might be possible to add some GUI tools for viewing/populating Sugar-specific manifest files, when desired. As a side note, I have an icon for Bundle which we've had around since the early design stages of Sugar, and the icon shown there isn't HIG compliant. Jake, would you be willing to update the bundle with a new icon if I supplied you with one? Eben 5) Meta-data kept in an INI rather than json a file? In INI format since its easier for hand-editing What about non- text meta-data, the preview image comes to mind, but an activity might be storing other non text blobs of meta-data. Any field in METADATA file can have _file suffix, in that case content of this field(substring w/o _file suffix) will be fetched from file inside of the bundle e.g. preview_file=filename-from-bundle to fill preview field. Thanks, sorry I missed the relevance of
Re: [Sugar-devel] Buddy Tagging (Was: GPA Goals Status)
On Sat, Jul 25, 2009 at 11:35 PM, Gary C Marting...@garycmartin.com wrote: Hi Eben, On 25 Jul 2009, at 16:26, Eben Eliason wrote: On Sat, Jul 25, 2009 at 10:59 AM, Gary C Marting...@garycmartin.com wrote: If you can find your previous group mock-ups, that would be great (been googling, wiki searching, and Spotlighting my email but haven't found them yet). Will do. I'll post them before the weekend is out. Cool. I've posted my earlier sketches to the Groups proposal page [1], along with comments on the ideas illustrated, and some thoughts relating them to Gary's designs. I also want to pose the question (as stated in the intro to my mockups): How do we use local group tagging as a stepping stone to open/closed groups? Eben [1] http://wiki.sugarlabs.org/go/Design_Team/Proposals/Groups ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Buddy Tagging (Was: GPA Goals Status)
On Sat, Jul 25, 2009 at 10:59 AM, Gary C Marting...@garycmartin.com wrote: Hi Eben, On 25 Jul 2009, at 03:01, Eben Eliason wrote: On Wed, Jul 22, 2009 at 1:17 PM, Gary C Marting...@garycmartin.com wrote: On 21 Jul 2009, at 23:51, Caroline Meeks wrote: On Tue, Jul 21, 2009 at 4:15 PM, Gary C Martin g...@garycmartin.com wrote: Hi Greg, On 21 Jul 2009, at 14:51, Greg Smith wrote: I may also add a feature to share a file from one computer to another. I want to see a lesson plan needing that first. Then I'll try out the suggestions recently posted to the list before I ask for a new feature. Have you tried using the Send to -- friend Journal feature? Obviously you need local collaboration working first, and added some friends: http://wiki.sugarlabs.org/go/0.84/0.83.5_Notes#Journal_entry_palette Send to sends to one person and we need to have one person (the teacher in this use case) send to everyone in the class/neighborhood. That said, I wonder if we can use this as a work around while we wait for designers and programmers to figure out the usecase. Is there a clever human engineering solution that would quickly allow each kid to send it to two other kids and get full coverage quickly? sort of like a calling tree? I think what I'm asking is how could I in a classroom management situation set up file sending tree quickly that includes everyone and doesn't cause too much chaos and is resilient to kids being absent and some kids being socially isolated. One of the 0.86 roadmap items was buddy tagging, but think it may have slipped: http://wiki.sugarlabs.org/go/Tagging_Proposal Here's some random misc. thoughts - Buddy tagging questions: 1) Can only add tags to myself? In this, case a teacher would need to get each of her class to add a specific unique tag themselves class_greentree7 (or she could add it before handing out the sticks). This tag would be visible/searchable in the neighbourhood by anyone on the same network/server. Anyone on the same network/server could use the send to -- class_greentree7 to send items to the whole class. Other people could potentially tag themselves as class_greentree7, the teacher could see this in the neighbourhood, if she checked, but class_greentree7 could potentially not be exclusive if she isn't watching. Have you read the design specification for groups as they were initially envisioned? (some details may have changed since this was written, but I think you'd find it useful background, and it answers some of your questions.) http://wiki.laptop.org/go/Specifications/Groups Thanks for the reminder :-) yes I'd read this a while back (but wasn't sold at the time, though it's a good starting discussion). FWIW this document is over on SL as well: http://wiki.sugarlabs.org/go/Design_Team/Specifications/Groups I still think that adding groups is a logical and even necessary extension of Sugar as it exists now, so I'd urge you not to try to solve all the problems that groups are designed to solve with tagging alone. Or, perhaps an early implementation of groups can come out of your work as well. OK, so I'd suggest my 1) above description of self tagging (a personal profile), replaces the use cases for Open groups. The open groups will naturally form by users self tagging their interests, projects, or being asked to enter some after school club name, etc. This is an interesting observation, but I think that open groups and self-tagging are still separate ideas and individually useful. Self-tagging: allows kids to identify themselves as anything they choose, allowing others to search for them by topic or interest. Any number of kids can apply the same tag at will, and there is no limit to the number or types of tags that one attributes to oneself, so the possibility of lying is present. These tags serve solely as an item to search on, and don't provide a structure for collaboration or sharing. Open groups: allow kids to self-organize into groups in an open but constrained way. The formalization of the group means that, unlike tags, any group one is a part of will appear in a filter in the Groups view. The group creation process enables a single individual to send invitations to the initial group members, so that only one needs to actually type the group name (preventing mistakes). Moreover, while anyone in an open group may freely invite others to it (hence, the open name), no child outside the group can self-tag so as to become a member of the group without their knowledge. The formality (not the best word, but oh well) of the open group provides a structure for sharing and collaborating with group members. So, to conclude: self-tagging is great for search and discovery. Open-groups are a mechanism for kids to self-organize (eg. for class projects) in a structured way so that actions like send to [my group] or share with [my group] are possible. Pro: Clean design. I can
Re: [Sugar-devel] Full screen view - making the the restore button go away
Sounds like a fine idea to me. It's probably one of the nice to have features that just never got implemented. Eben On Fri, Jul 24, 2009 at 7:25 PM, Sayamindu Dasguptasayami...@gmail.com wrote: Hello, Is there a reason why the square restore button in full screen mode does not go away after a timeout (temporarily - unless you move the cursor) ? Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Book bundles and Read
On Thu, Jul 23, 2009 at 5:09 PM, Gary C Marting...@garycmartin.com wrote: On 23 Jul 2009, at 21:36, Jim Simmons wrote: Gary, What Scotty wants is a listing that can be easily browsed, and which shows image files for book covers. Yes, book cover images, is the big missing feature with current Journal abilities when accessing external media (along with a Journal thumb view, but hopefully that feature is coming). We should provide a way to populate the previews for the entries within content bundles. With this, and a grid view, we'd be in good shape. The problem I have with USB devices on the Journal is that they are listed in descending order by the date and time they were created. Even a few hundred books on a USB stick isn't all that easy to manage. (I have an SD drive with 2 GB worth of comic books and it really bugs me that they aren't in alphabetical order). Searching is fine if you know what you're The Journal is spec'd to have sorting capability, and Tomeu has done some work toward this end. It should be possible to sort by date, title, type, and participants. looking for. In this case the kid might be asked by his teacher to pick out a book from the conduct of life collection and do a report on it. The teacher asking students to pick out a book from the 'conduct of life' is the easy case :-) The kid just types 'conduct of life' into the Journal search filed, and just those books are listed. All that the USB stick would have needed is for those books to be in a directory called conduct of life, or for that text to be part of each books file name title. Like any real bricks and mortar library, putting the books in some sort of order, up front, really helps the punters in finding what they are looking for ;-) In that case the kid really needs to be able to search the USB drive as if it was a real bookshelf, look at the book covers, read descriptions, etc. What I had proposed would allow that. Yes, Journal type meta-data is not supported on external media unfortunately (though that is a really tough problem to solve). I guess you can make the argument for creating custom file layouts / index that you implement in Journal (E), so that you can stick book thumbs and metadata in known names/folders... But this is just a Oh. That's what I was suggesting above. I guess you're right. It would be very useful, though... re-implementation of the data-store format from Tomeu, so no need to re-invent or re-implement, just use the existing format for free! What this would mean for the Journal is allowing external volumes/ media to be flagged in some way so that the Journal would read and display their data just like from the local Sugar data-store. I guess this could be very low hanging fruit, you'd need to ask Tomeu... The We have discussed the idea of offering an Extend my Journal option for external media. It would be particularly useful for SD cards which can be more or less permanently installed. I think it's an intriguing idea. flag could be something as simple as an empty root level file on the volume named to indicate the volume is in data-store format and should be treated as such. The idea is to provide books to kids that don't have access to the Internet, either because it isn't available or because of parental concern. +1 Eben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Buddy Tagging (Was: GPA Goals Status)
On Wed, Jul 22, 2009 at 1:17 PM, Gary C Marting...@garycmartin.com wrote: On 21 Jul 2009, at 23:51, Caroline Meeks wrote: On Tue, Jul 21, 2009 at 4:15 PM, Gary C Martin g...@garycmartin.com wrote: Hi Greg, On 21 Jul 2009, at 14:51, Greg Smith wrote: I may also add a feature to share a file from one computer to another. I want to see a lesson plan needing that first. Then I'll try out the suggestions recently posted to the list before I ask for a new feature. Have you tried using the Send to -- friend Journal feature? Obviously you need local collaboration working first, and added some friends: http://wiki.sugarlabs.org/go/0.84/0.83.5_Notes#Journal_entry_palette Send to sends to one person and we need to have one person (the teacher in this use case) send to everyone in the class/neighborhood. That said, I wonder if we can use this as a work around while we wait for designers and programmers to figure out the usecase. Is there a clever human engineering solution that would quickly allow each kid to send it to two other kids and get full coverage quickly? sort of like a calling tree? I think what I'm asking is how could I in a classroom management situation set up file sending tree quickly that includes everyone and doesn't cause too much chaos and is resilient to kids being absent and some kids being socially isolated. One of the 0.86 roadmap items was buddy tagging, but think it may have slipped: http://wiki.sugarlabs.org/go/Tagging_Proposal Here's some random misc. thoughts - Buddy tagging questions: 1) Can only add tags to myself? In this, case a teacher would need to get each of her class to add a specific unique tag themselves class_greentree7 (or she could add it before handing out the sticks). This tag would be visible/searchable in the neighbourhood by anyone on the same network/server. Anyone on the same network/server could use the send to -- class_greentree7 to send items to the whole class. Other people could potentially tag themselves as class_greentree7, the teacher could see this in the neighbourhood, if she checked, but class_greentree7 could potentially not be exclusive if she isn't watching. Have you read the design specification for groups as they were initially envisioned? (some details may have changed since this was written, but I think you'd find it useful background, and it answers some of your questions.) http://wiki.laptop.org/go/Specifications/Groups I still think that adding groups is a logical and even necessary extension of Sugar as it exists now, so I'd urge you not to try to solve all the problems that groups are designed to solve with tagging alone. Or, perhaps an early implementation of groups can come out of your work as well. Pro: Clean design. I can search the neighbourhood to find other's tags (social network). Individual kids can form groups by agreeing to use matching tags (school_play). I think this is definitely the place to start with tagging. I'd like to see the ability for kids to provide tags for themselves in a profile of sorts. It would also be nice to expose these profiles in the secondary palettes for people in the UI. Perhaps one's own palette allows editing. We could also expose even more details in the about me section of settings. Con: I can't make my own ad-hoc tag lists of friends (friday_art_club, people_who_helped_me), I have to rely on each of them to self tag. I think this con is acceptable, for now. I understand the desire to allow anyone to tag anyone, but it's not clear how to expose this in the UI clearly, and it moves into the realm of groups. Of course, groups are also mutual sets of people, rather than local labels for people. Equivalent to: Joining (or leaving) mail lists (ie. you can join/ leave, you can't force others to join/leave) Again, this kind of membership issue is really a feature of groups, and I think the proposal I linked to handles it rather well. In most cases membership is at will, but there are special provisions in the UI for, say class_greentree7 so the teacher can manage the class group as needed. 2) Can I only tag other buddies? These tags would simply be local to my install of Sugar for my one use, with nothing shared. Pro: Simple. Clean design. I can search the neighbourhood for buddy tags I've added. I can make my own personally relevant ad-hoc tag lists to work with those groups of people I want to work with. I have full control over who I tag with what. Con: No sharing of tags with others, no discovery of others through their own tags. Each person needs to create their own tag lists (duplication of effort if, say, each member of the school_play each has to school_play tag all other members of the school play). Yes, I don't think this is powerful enough for kids. That is, the primary benefit of having a profile is that each kid individually will want to fill theirs out, and the whole neighborhood benefits as a
Re: [Sugar-devel] Choosing to merge: a mockup
Sorry, I've let some threads linger in my inbox... On Mon, Jul 13, 2009 at 5:22 AM, Tomeu Vizosoto...@sugarlabs.org wrote: On Tue, Jul 7, 2009 at 20:12, Benjamin M. Schwartzbmsch...@fas.harvard.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mockup: http://dev.laptop.org/~bemasc/merge_share_selection_mockup.png The mockup doesn't look bad, though I wonder a few things. I think this would work well visually if the merge visual were a real-time representation of the group currently working on the activity, rather than an icon. (This may be your intent, but I wanted to make it explicit). In the same vein, I think your XO should appear above the same activity icon, so that the picture painted is clear...if you click on work alone, you'll have your own copy and they'll have theirs. I'd also greatly simplify the text to something like Join and Work alone. Idea: If I resume an Activity session from my Journal, and there is already a session in progress with the same activity_id, and the Activity in question supports automerge, then Sugar will show me the above screen, asking me whether I want to merge my work with the shared session, or to work alone. This is enough to enable basic asynchronous collaboration. Visual details aside, I'm still unsure if we actually need to expose this choice. I'm still partial to doing the merge/join automatically if the entry being opened is the most recent in the history, and opening it as a separate instance otherwise. The screen simply has two buttons. One is the image of the shared session in question, identical to the one shown in the Neighborhood View. The other is an image of my XO icon. The text below each button explains its purpose, and also gives the name of the shared session and the local session, as these may have diverged. Knowing the names may help the user to decide whether or not to merge. That's a good point. Perhaps I have to retract my statement about the simplified text, though perhaps it could still be shortened some. As I understand it, the current activity architecture requires an activity to know if it is a joining a shared session as soon as initialization begins, so activity startup cannot proceed until the user makes a choice. Perhaps we should review this. Is providing the choice in the launcher screen our best option user experience-wise? Or would be better to leave it entirely in the activity's hands if it was possible? Yeah, perhaps. Another thought, if there has to be Some Way to prevent automatic merge is to offer Resume alone next to the Resume and Resume with options, to override the merge and start a separate session. Eben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GSoC Groupthink Update: SharedTextDemo-4
On Fri, Jul 17, 2009 at 1:23 PM, Walter Benderwalter.ben...@gmail.com wrote: On Fri, Jul 17, 2009 at 12:35 PM, Benjamin M. Schwartzbmsch...@fas.harvard.edu wrote: Walter Bender wrote: On Thu, Jul 16, 2009 at 10:06 PM, Benjamin M. Schwartzbmsch...@fas.harvard.edu wrote: 1. Any session saved in the Journal that was previously shared, will be shared again with the same scope upon resume. 2. If there is an existing shared session visible with the same activity_id, the activity will join that session. I think this is good, but again want to state that I personally feel that this should happen only when the session being resumed is the most recent in the individuals thread. It should be possible to open older versions of the session without instigating a merge. This behavior is good enough for me. However, it does preclude users from working privately on the results of a shared session, unless they totally Perhaps this could be accommodated by allowing different types of resume actions. For instance, we've long desired to have both start and start with , where the latter would reveal a submenu allowing a child to start an activity in a neighborhood scope, or with individual friends (and later groups). Perhaps we could likewise have resume and resume alone, or something similar, so that the choice can be made in the process of resuming the session. deactivate their network connection. I could add this ability to work privately to groupthink's GroupActivity superclass, or it could be added to sugar's Activity class. A number of other interesting behaviors, such as forking an existing document, are also unavailable in the present system. Maybe an option for keep could be to keep a private copy? This has always been my mental model for the keep a copy button (not the keep button). I think my thinking is similar to Ben's, here. I think this makes sense. Keep a copy would reset the sharing scope to private, and create a new activity_id. It's hard to reason about, but I think this makes sense for a versioned datastore as well, where creating a copy is only necessary if you want to break the history (otherwise Keep is sufficient to make a checkpoint in the version history). Yup. However, this still doesn't allow temporary private work. In order to be able to work privately on a shared document, and then later merge it back into the shared stream, users would need to be able to choose to work privately for a single session, without altering the activity_id. It's not yet clear to me how important this feature is. --Ben A private copy can be shared again. So it seems the real question is That's true, but if the new copy is private, it will have a new tree_id and be part of a new thread, with a separate history. It would be possible to manually merge this with the former thread, or share it with others in its current thread, but the two threads would not be automatically merged. one of merging. If each of us are working on different versions and we want to share again, we need some reconciliation mechanism. I would argue that for the time being, that should be a manual process. I think manual merge should always be the fallback. However, I like the idea of supporting automatic merge of the most recent versions from several individuals in a collaboration thread. Eben -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Click response areas
On Fri, Jul 17, 2009 at 9:55 AM, Frederick Grosefgr...@gmail.com wrote: On Fri, Jul 17, 2009 at 9:25 AM, Eduardo H. Silva hoboprim...@gmail.com wrote: ... (Students at the Gardner Pilot Academy...) - Clicked on drop down instead of icon (e.g. clicking stop they put the cursor over the stop sign then saw the drop down text saying Stop then clicked on that and nothing happens. They should click directly on the stop sign itself. Stop is probably the first toolbar button a user/kid uses, so I think it is normal that they don't yet know how it works. Is there a sufficient reason that the button label is not click-responsive? No, this is a long-standing bug. The primary palette which serves as a label for the button should be a clickable extension of the button itself. Eben Having a larger target is a benefit for all users. Radio buttons and check marks that respond when their text labels are clicked are more usable, as well. --Fred ... ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Initial implementation of toolbars design
On Sat, Jul 11, 2009 at 10:23 AM, Gary C Marting...@garycmartin.com wrote: On 11 Jul 2009, at 14:40, Aleksey Lim wrote: On Sat, Jul 11, 2009 at 11:12:31AM +0200, Simon Schampijer wrote: a) DESIGN: discuss the design further and get some mockups together, one question that came up is: do we always have a one line secondary tool bar? Do you mean hiding sub-toolbars like palettes? I'm using new toolbar in Memorize, and should say - its much useful to have persistent sub-toolbar(and not auto-hiding them like palettes) Ebens designs describe both interaction methods: 1). If you hover over one of the new tab replacement buttons the palette appears (over the top of the canvas) and will auto-hide if you move the mouse way (just like any normal palette) 2). If you click one of the new tab replacement buttons the palette appears (and shifts the canvas down the screen) and is locked in place. Clicking the button a 2nd time unlocks it so it behaves like a regular palette again. Yup, that's the idea. I think it should be up to the activity, by the way, to decide if any of the secondary toolbars are locked in when a new activity instance is created. For instance, Paint might decide that making the colors available by default is the wise choice. We should also institute policy for retaining toolbar state in the metadata for a given activity entry in the Journal, so that resuming restores that context. Perhaps this is something that the toolkit can do so that activity doesn't have to think about it. How would more complex widgets like the color chooser look like http://wiki.sugarlabs.org/go/File:ColorToolButton.png ? Or would they open from the secondary palette? I'm personally, +1 for http://wiki.sugarlabs.org/go/Design_Team/Designs/Toolbars#11 Just to be clear, this new toolbar design is in no way intended to replace palettes in general. Instead, it's provided as a unique alternative to tabs that allows palette-like interaction, but also allows these secondary toolbars to be locked in place persistently, which can be of great usefulness. Therefore, we needn't ask ourselves how does this palette look/work in the new toolbar design? at all. We should be asking which of these palettes would work better functionally as a secondary toolbar?. I think that Paint, for instance, would gain heaps of usability if the colors were a secondary toolbar, and that were shown by default. That doesn't mean that Write, for instance, necessarily needs to replace the current color chooser palette. It's should be up to activities to decide what parts of the UI are best suited to the two modes. Both primary and secondary toolbars can have as many normal palette buttons as desired. I guess one unanswered question is do you allow the stacking of more than 2 rows of toolbar... And, how much work is going to be needed on This is something we tossed around a little bit while designing them. I think the answer is no, personally, since it adds a lot more complexity to the UI, and also begins to consume too much of the screen. I'm hoping that [primary toolbars secondary toolbars palettes] are sufficient for most use cases here; we don't want to wind up with MS Word-like feature complexity! That said, if we do support it, I think the rule is basically that closing any parent toolbar hides all of its children, and reopening a parent toolbar that had child toolbars open when it was last hidden should reveal all those same children open as they were. But again, I'd much rather just support one level of secondary toolbars. all the Activities if you start hand redesigning and customising each edge case. I think the current colour palette in Write would work as Yup. is, at least that's how I was going to show it in a mockup, Activity bar - text bar below - existing drop down colour palette from its One advantage of this design is that the primary toolbar is always visible, and secondary toolbars can be shown or hidden as needed. The mockups of Browse and Paint try to illustrate how useful this can be in defining a set of core tools that are always—or nearly always—applicable to interacting with the activity. In the case of browse, the forward and back buttons, address bar, and bookmarking button are always available in the primary toolbar. In Paint, some of the core painting tools are surfaced. So, the idea here is to define a primary toolbar which contains a) the core set of tools/controls and b) toolbar buttons for the secondary sets of tools/controls. In the case of Write, I'd expect some of the basic text editing controls (bold, italic, underline, font-size, font, for example) to be surfaced in the primary toolbar, while tables, images, paragraph formats, and other secondary features each had a secondary toolbar of their own. In this way, it would be possible to reveal the table controls, while retaining the basic text controls, which is clearly quite useful since you can edit text within a table.
Re: [Sugar-devel] Nobody understands Keep
On Fri, Jul 10, 2009 at 5:28 AM, Tomeu Vizosoto...@sugarlabs.org wrote: On Fri, Jul 10, 2009 at 05:41, Eben Eliasone...@laptop.org wrote: On Thu, Jul 9, 2009 at 7:55 PM, Eduardo H. Silvahoboprim...@gmail.com wrote: 2009/7/9 Tomeu Vizoso to...@sugarlabs.org: On Thu, Jul 9, 2009 at 12:29, Martin Denglermar...@martindengler.com wrote: On Thu, Jul 09, 2009 at 11:22:16AM +0100, Daniel Drake wrote: On Thu, 2009-07-09 at 10:45 +0100, Martin Dengler wrote: On Thu, Jul 09, 2009 at 09:52:23AM +0100, Daniel Drake wrote: Nobody in the world seems to understand the Keep button. People think it's for regular saving and you should do it before you close or switch away from your activity. That's not far from the truth, right? At least in any work-losing or surprising way... It's far from the truth in that it's not normally what you want to do. My quoting-foo is bad, so I've caused confusion (in myself, too :)). To save your work, simply click the Stop button or change so that another activity has focus. If you click Keep, you'll end up with 2 copies - one from when you clicked Keep, and one from when you clicked Stop (or focused on another activity). As far as I understand it, Keep is useful for these types of scenarios: - you've done a lot of work but now it's time to refactor/reorganize the whole thing. However you want to keep a copy of the rough version you have now, as insurance or perhaps for reference while you re-mangle the work. - you've made a template for something, now you want to save that template (as a blank template) before starting on a version where you fill in the content. This is a great explanation -- it should be in the HIG or something. But the biggest problem is how do we explain this to users without them having to read the HIG (or manual)? Should be called Keep a copy? +1 For a while, in the pt_PT translation of Sugar I did, I named the Keep button as Keep a copy. I urge again that keep a copy is not what is intended, in the long run. Without proper versions, of course, this is effectively how it behaves. Therefore, it's no surprise many saw it this way. But with versions, the keep button is actually a keep new version button. As mentioned before, a new version retains the tree_id, whereas a true copy does not. But are you meaning that we should name the current one Keep a copy and when we have versions add Keep? No, no. I'm urging that we name it Keep new version now if we rename it, so that it's meaning doesn't change down the road when versions are introduced. Eben Regards, Tomeu Since versions are on the way, we should make sure to clarify the distinction! Eben Regards, Tomeu Daniel Martin ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Nobody understands Keep
On Fri, Jul 10, 2009 at 10:05 AM, Martin Denglermar...@martindengler.com wrote: On Fri, Jul 10, 2009 at 10:01:19AM -0400, Eben Eliason wrote: On Fri, Jul 10, 2009 at 5:28 AM, Tomeu Vizosoto...@sugarlabs.org wrote: But are you meaning that we should name the current one Keep a copy and when we have versions add Keep? No, no. I'm urging that we name it Keep new version now if we rename it, so that it's meaning doesn't change down the road when versions are introduced. Keep new version seems a lot closer to a description of the implementation than of the user-desired result. Unless this new version becomes the active one (i.e., the one upon which the user continues to work, assuming they don't close the application), isn't the result of the button press better called Keep[ing of a] backup version? I'm happy to entertain other terminology. All I'm really trying to get across is that, technically, this action is strictly not what I interpreted as keep a copy in the presence of versions, and I don't want to confuse the terminology later by mixing up the terms. I'd be equally satisfied, I think, by finding a better term for what I'm presently describing as keep a copy, wherein a brand new tree_id is assigned to the copy, detaching it from the history (and collaboration scope) of the original. The fundamental issue is whether or not version/collaboration history is retained with the action, so let's ensure that we name both of these types of copy operations at the same time, even if we only have one of them for now, so that it can be extended later. Ben's suggestion of checkpoint could work. Perhaps Keep checkpoint would be better to retain the action. You're right that it's more like keep backup versionthat is, the keep operation which retains the tree_id basically writes the current state of the activity as a version (the just-now-previous one), and allows you to continue working in the most current one. No branching, in the traditional sense, happens here. Eben Regards, Tomeu Eben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Nobody understands Keep
On Fri, Jul 10, 2009 at 10:29 AM, Tomeu Vizosoto...@sugarlabs.org wrote: On Fri, Jul 10, 2009 at 16:25, Eben Eliasone...@laptop.org wrote: On Fri, Jul 10, 2009 at 10:05 AM, Martin Denglermar...@martindengler.com wrote: On Fri, Jul 10, 2009 at 10:01:19AM -0400, Eben Eliason wrote: On Fri, Jul 10, 2009 at 5:28 AM, Tomeu Vizosoto...@sugarlabs.org wrote: But are you meaning that we should name the current one Keep a copy and when we have versions add Keep? No, no. I'm urging that we name it Keep new version now if we rename it, so that it's meaning doesn't change down the road when versions are introduced. Keep new version seems a lot closer to a description of the implementation than of the user-desired result. Unless this new version becomes the active one (i.e., the one upon which the user continues to work, assuming they don't close the application), isn't the result of the button press better called Keep[ing of a] backup version? I'm happy to entertain other terminology. All I'm really trying to get across is that, technically, this action is strictly not what I interpreted as keep a copy in the presence of versions, and I don't want to confuse the terminology later by mixing up the terms. I'd be equally satisfied, I think, by finding a better term for what I'm presently describing as keep a copy, wherein a brand new tree_id is assigned to the copy, detaching it from the history (and collaboration scope) of the original. The fundamental issue is whether or not version/collaboration history is retained with the action, so let's ensure that we name both of these types of copy operations at the same time, even if we only have one of them for now, so that it can be extended later. Ben's suggestion of checkpoint could work. Perhaps Keep checkpoint would be better to retain the action. You're right that it's more like keep backup versionthat is, the keep operation which retains the tree_id basically writes the current state of the activity as a version (the just-now-previous one), and allows you to continue working in the most current one. No branching, in the traditional sense, happens here. Should we discuss this in sugar-devel? Why not asking any of the teachers in IAEP what is more natural for them? Makes sense to me, as long as we can convey to them first the distinction between the two. The problem at hand is that keep a copy makes perfect sense, until you toss in this alternate action to confuse things. As another note, I have another reason why I interpreted keep a copy to mean new tree_id, and not just new version. Looking at the design mockups for the action/object views of the Journal, we designed the object view to show only the most recent version of any object. That is, each object is represented just once in that list. Here, it seems like keep a copy should mean give me a new object in this list; Keeping a version is just an action which snapshots a previous state of the current object, without making a true copy of it. Maybe we could always refer to versions as history in Sugar (seems logical, given the Journal metaphor!). Then, we could call what the new tree_id case keep a copy as I initially suggested, and the new version_id case keep in history, to indicate that pressing it will add a new listing in the history of the current object. Eben Regards, Tomeu Eben Regards, Tomeu Eben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Datastore redesign
On Thu, Jul 9, 2009 at 8:00 AM, Tomeu Vizosoto...@sugarlabs.org wrote: On Mon, Jul 6, 2009 at 16:33, Eben Eliasone...@laptop.org wrote: On Mon, Jul 6, 2009 at 10:02 AM, Sascha Silbesascha-ml-ui-sugar-de...@silbe.org wrote: On Mon, Jul 06, 2009 at 12:29:53PM +0200, Tomeu Vizoso wrote: Agreed. I have to say that your proposal is excellent, congratulations! Thanks, I'm flattered. :) Is the asynchronous API design useful enough to warrant more complex implementation? I'm not sure, but I think that whatever decision we take should be made based on actual usage of the DS. What about proposing an example of how an existing activity would be modified to use the new API? OK, will work on one. - For save() calls activity needs to wait for result (containing new version_id) before it can invoke save() again for the same object which can take quite some time if save() is sync - especially if other activities are saving at the same time. What about having a separate call that returns synchronously a new tree_id and/or version_id? Interesting idea, need to think about it. As we're going to use UUIDs not using requested versions shouldn't be an issue (for other version number schemes like the one you propose below holes in the numbering could be troublesome). I think holes can be expected, so we should definitely be prepared for them. Making the API fully asynchronous is the cause for much of the complexity of my proposal, but if we eliminate the queueing the response times for write accesses and checkout() can be very long even for unrelated operations. Why for unrelated operations? Because we're serializing VCS operations. They are IO bound (more specifically: disk bound) and parallelisation would only lead to IO starvation, especially for HDDs. # do we want an optimized way to determine (only) the branch HEADs of a given tree_id? This depends on the intended UI. My opinion is that if we branch at every interesting modification (triggered by the activity detecting an interesting change or by the user clicking on the Keep button), we I don't think we need to branch in these instances. These events should create new versions, but not necessarily new branches. In my proposal, branch is not a concept directly exposed to the user. Is just an artefact that allows the journal to display the relevant info to an user. If we branch at the following events, displaying only HEADs of branches in the journal list view makes sense for the user: - new tree_id, - resume entry, - keep button, - after a big change in the activity model (user deletes the whole drawing, etc). There are other ways to manage what we want, but this approach made it very easy to implement. Just to make sure I'm understood, I see why using branches this way may seem conceptually wrong, it's not how we would work in a VCS or CMS. But by creating new branches at those points and displaying only HEADs of branches in the list view is the simplest way I found of displaying the relevant entries in a robust way (resisting activity crashes). That's fine, assuming these are actually the entries we want to show, but I'm not sure that's always the case. For instance, we might show only the most recent version in the object view, while showing each version within the action view. If we store action-objects as Ben proposed, we may have an entirely different way of querying what should be shown in the actions view anyway. We've also had some ideas on how to expose the branching structure within the version popup, in which case branching as one would in a VCS would make more sense. Eben would like to display in the object list all the HEADs of each branch in each tree_id. In that case yes, we need a way to retrieve that list that is fast on both the client and the server side. My imagined usage of branches was to create them automatically upon altering a non-HEAD version. This makes sense to me, personally. A user basing off an old version could mean the newer version is broken (in that case promoting the new version to the HEAD of the current branch makes more sense) or that (s)he uses the older version as a kind of template to create derivates (so creating a branch would make most sense). But I'm open to alternative suggestions. We'd most likely need a way to explicitly create branches then. # using symlink instead of hardlink for incoming queue since we want to support directory trees, not just files What justifies this new requirement? That it's a) of use to activities (IIRC some of them use ZIP files right instead now), This has its own merits, though. Encapsulating the related files as a single archive makes transporting the file around, or sending it to a friend, trivial. It's good for the same reason that activity bundles are good. But this may be considered an internal implementation detail of the DS, unless we want to support users directly
Re: [Sugar-devel] Nobody understands Keep
On Thu, Jul 9, 2009 at 8:03 AM, Gary C Marting...@garycmartin.com wrote: On 9 Jul 2009, at 11:29, Martin Dengler wrote: On Thu, Jul 09, 2009 at 11:22:16AM +0100, Daniel Drake wrote: On Thu, 2009-07-09 at 10:45 +0100, Martin Dengler wrote: On Thu, Jul 09, 2009 at 09:52:23AM +0100, Daniel Drake wrote: Nobody in the world seems to understand the Keep button. People think it's for regular saving and you should do it before you close or switch away from your activity. +1 That's not far from the truth, right? At least in any work-losing or surprising way... It's far from the truth in that it's not normally what you want to do. My quoting-foo is bad, so I've caused confusion (in myself, too :)). To save your work, simply click the Stop button or change so that another activity has focus. If you click Keep, you'll end up with 2 copies - one from when you clicked Keep, and one from when you clicked Stop (or focused on another activity). As far as I understand it, Keep is useful for these types of scenarios: - you've done a lot of work but now it's time to refactor/ reorganize the whole thing. However you want to keep a copy of the rough version you have now, as insurance or perhaps for reference while you re-mangle the work. Exactly. - you've made a template for something, now you want to save that template (as a blank template) before starting on a version where you fill in the content. Not exactly. This would work, but I wouldn't call this a recommended use. To start a new document from a template, it would be more appropriate to Create a copy (which should exist in the Journal itself), or Keep a copy (which would do the same thing, but from within the activity) This is a great explanation -- it should be in the HIG or something. Hmmm, this still does not cover the special behaviour that Sugar now treats those Journal entries with. All these entries will have the same activity_id, Sugar shell uses this ID to know if it already has Yes, that's intended. Keep actually means Keep a new version We don't have proper versions yet, but that's the model. an Activity resumed. If an Activity with a matching activity_id is already instanced, resuming one of the older/newer entries will just switch you to the existing instance (with no change of content). Collaborating, with the Sugar shell treating any single entry in this long chain of entries as the same, is likely to cause quite some confusion for those involved as well... Perhaps visually showing all 'kept' entries as one single block (not multiple entries), with the past ones visually 'depreciated' in some This was our thought behind the design mockups for the object view. There would be one entry per object in the list, with a way to expand or reveal past versions. The opposite, however, is true of the design for the action list. Each version is created as part of a unique activity session, so each of these would be recorded as a distinct action, and refer to the associated version. way (like old undo states), might help? Perhaps the keep button is just wrong altogether. I think it's really important to have a manual method of invoking the equivalent of saving. Maybe labeling the Keep button something like Keep extra version would help. Maybe Sascha's GSoC version work will help us sort out the correct behaviour here. Yes, it may. Eben Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Nobody understands Keep
On Thu, Jul 9, 2009 at 8:03 AM, Tomeu Vizosoto...@sugarlabs.org wrote: On Thu, Jul 9, 2009 at 12:29, Martin Denglermar...@martindengler.com wrote: On Thu, Jul 09, 2009 at 11:22:16AM +0100, Daniel Drake wrote: On Thu, 2009-07-09 at 10:45 +0100, Martin Dengler wrote: On Thu, Jul 09, 2009 at 09:52:23AM +0100, Daniel Drake wrote: Nobody in the world seems to understand the Keep button. People think it's for regular saving and you should do it before you close or switch away from your activity. That's not far from the truth, right? At least in any work-losing or surprising way... It's far from the truth in that it's not normally what you want to do. My quoting-foo is bad, so I've caused confusion (in myself, too :)). To save your work, simply click the Stop button or change so that another activity has focus. If you click Keep, you'll end up with 2 copies - one from when you clicked Keep, and one from when you clicked Stop (or focused on another activity). As far as I understand it, Keep is useful for these types of scenarios: - you've done a lot of work but now it's time to refactor/reorganize the whole thing. However you want to keep a copy of the rough version you have now, as insurance or perhaps for reference while you re-mangle the work. - you've made a template for something, now you want to save that template (as a blank template) before starting on a version where you fill in the content. This is a great explanation -- it should be in the HIG or something. But the biggest problem is how do we explain this to users without them having to read the HIG (or manual)? Should be called Keep a copy? Careful, here. keep a copy really is a fundamentally different action. Keeping a copy will result in a new tree_id; Just keeping (or keeping a new version) will only result in a new version_id. We need to find a way to make these actions distinct. Eben Regards, Tomeu Daniel Martin ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Nobody understands Keep
On Thu, Jul 9, 2009 at 7:55 PM, Eduardo H. Silvahoboprim...@gmail.com wrote: 2009/7/9 Tomeu Vizoso to...@sugarlabs.org: On Thu, Jul 9, 2009 at 12:29, Martin Denglermar...@martindengler.com wrote: On Thu, Jul 09, 2009 at 11:22:16AM +0100, Daniel Drake wrote: On Thu, 2009-07-09 at 10:45 +0100, Martin Dengler wrote: On Thu, Jul 09, 2009 at 09:52:23AM +0100, Daniel Drake wrote: Nobody in the world seems to understand the Keep button. People think it's for regular saving and you should do it before you close or switch away from your activity. That's not far from the truth, right? At least in any work-losing or surprising way... It's far from the truth in that it's not normally what you want to do. My quoting-foo is bad, so I've caused confusion (in myself, too :)). To save your work, simply click the Stop button or change so that another activity has focus. If you click Keep, you'll end up with 2 copies - one from when you clicked Keep, and one from when you clicked Stop (or focused on another activity). As far as I understand it, Keep is useful for these types of scenarios: - you've done a lot of work but now it's time to refactor/reorganize the whole thing. However you want to keep a copy of the rough version you have now, as insurance or perhaps for reference while you re-mangle the work. - you've made a template for something, now you want to save that template (as a blank template) before starting on a version where you fill in the content. This is a great explanation -- it should be in the HIG or something. But the biggest problem is how do we explain this to users without them having to read the HIG (or manual)? Should be called Keep a copy? +1 For a while, in the pt_PT translation of Sugar I did, I named the Keep button as Keep a copy. I urge again that keep a copy is not what is intended, in the long run. Without proper versions, of course, this is effectively how it behaves. Therefore, it's no surprise many saw it this way. But with versions, the keep button is actually a keep new version button. As mentioned before, a new version retains the tree_id, whereas a true copy does not. Since versions are on the way, we should make sure to clarify the distinction! Eben Regards, Tomeu Daniel Martin ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Datastore redesign
On Mon, Jul 6, 2009 at 10:02 AM, Sascha Silbesascha-ml-ui-sugar-de...@silbe.org wrote: On Mon, Jul 06, 2009 at 12:29:53PM +0200, Tomeu Vizoso wrote: Agreed. I have to say that your proposal is excellent, congratulations! Thanks, I'm flattered. :) Is the asynchronous API design useful enough to warrant more complex implementation? I'm not sure, but I think that whatever decision we take should be made based on actual usage of the DS. What about proposing an example of how an existing activity would be modified to use the new API? OK, will work on one. - For save() calls activity needs to wait for result (containing new version_id) before it can invoke save() again for the same object which can take quite some time if save() is sync - especially if other activities are saving at the same time. What about having a separate call that returns synchronously a new tree_id and/or version_id? Interesting idea, need to think about it. As we're going to use UUIDs not using requested versions shouldn't be an issue (for other version number schemes like the one you propose below holes in the numbering could be troublesome). I think holes can be expected, so we should definitely be prepared for them. Making the API fully asynchronous is the cause for much of the complexity of my proposal, but if we eliminate the queueing the response times for write accesses and checkout() can be very long even for unrelated operations. Why for unrelated operations? Because we're serializing VCS operations. They are IO bound (more specifically: disk bound) and parallelisation would only lead to IO starvation, especially for HDDs. # do we want an optimized way to determine (only) the branch HEADs of a given tree_id? This depends on the intended UI. My opinion is that if we branch at every interesting modification (triggered by the activity detecting an interesting change or by the user clicking on the Keep button), we I don't think we need to branch in these instances. These events should create new versions, but not necessarily new branches. would like to display in the object list all the HEADs of each branch in each tree_id. In that case yes, we need a way to retrieve that list that is fast on both the client and the server side. My imagined usage of branches was to create them automatically upon altering a non-HEAD version. This makes sense to me, personally. A user basing off an old version could mean the newer version is broken (in that case promoting the new version to the HEAD of the current branch makes more sense) or that (s)he uses the older version as a kind of template to create derivates (so creating a branch would make most sense). But I'm open to alternative suggestions. We'd most likely need a way to explicitly create branches then. # using symlink instead of hardlink for incoming queue since we want to support directory trees, not just files What justifies this new requirement? That it's a) of use to activities (IIRC some of them use ZIP files right instead now), This has its own merits, though. Encapsulating the related files as a single archive makes transporting the file around, or sending it to a friend, trivial. It's good for the same reason that activity bundles are good. b) easy enough to achieve with the new design and c) leads to better delta compression and thus disk space effiency. # since an index rebuild can take a lot of time we need to provide UI feedback while doing that Any I/O operation can potentially take a lot of time, but with the current version of the DS rebuilding an index with a few thousands of entries is not so slow on the XO. We should never need to rebuild the index, so this new requirement might not be justified (given the current resources, all the other work we need to do, etc). OK, good to know index rebuilding is fast. So the simple, boolean API I proposed (check_ready() / Ready()) suffices. # detecting identical files across objects isn't as important since duplicates are mostly expected to occur as versions of the same object Based on how current activities are using the DS, this isn't like that. The most common case I have heard from the field are children downloading a PDF for reading several times. Oh, didn't know that, so it's a new requirement. An alternative to the current method for detecting duplicates is moving this task to activities, is that what you suggest? I'm ambivalent about it. On one hand it's not so easy to achieve in datastore (for various backends) and more indicative of UI deficiencies (why This might be the case, indeed. On other operating systems/browsers, this (downloading multiple copies if the link is clicked multiple times) is expected behavior. Perhaps we can work out some ways to make the UI clearer. did the children download the file several times in the first place; it's bandwidth wastage as well), on the other hand it might not
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
I like these terms, but I don't think they define the split I'm referring to. object-push and object-pull describe, sending an object to a friend and taking something from my friend's Journal respectively. Both of these types of sharing are object-sharing (the recipient gets the resulting object, with a new tree_id). The more I think about it, I kind of like the object-sharing and activity-sharing distinction, since in all of our high-level outlines of Sugar we break the UI down into 3 core components: people, activities, and objects. In this paradigm, we have: object-sharing: the transfer of objects from people to people, via push (send to) or pull (view published journal) activity-sharing: collaboration among two or more people within an activity, acting on a shared object or objects Can someone phrase this more clearly? Eben On Mon, Jul 6, 2009 at 10:56 AM, Benjamin M. Schwartzbmsch...@fas.harvard.edu wrote: Eben Eliason wrote: PS. I think we need to come up with some better terminology to distinguish between collaboration sharing and journal sharing. That would make this much easier to talk about. I've been using the terms object push and object pull. --Ben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Sat, Jul 4, 2009 at 2:00 AM, Andrés Ambroisandresambr...@gmail.com wrote: On Saturday 04 July 2009 12:31:48 am Eben Eliason wrote: On Fri, Jul 3, 2009 at 11:19 PM, Gary C Marting...@garycmartin.com wrote: On 4 Jul 2009, at 03:13, Eben Eliason wrote: snip PS. I think we need to come up with some better terminology to distinguish between collaboration sharing and journal sharing. That would make this much easier to talk about. You're not kidding there :-) should we call both sharing, but differentiate it with a modifier, like collaboration vs. document, or maybe activity vs. object. This latter might be the best I've thought of so far. activity sharing is real-time collaboration; object-sharing is public Journal entries, the output. Thoughts? Better suggestions? How about publishing? It seems to me the most concise way to express the action of making content available to a wider audience. That's a pretty good suggestion. The only aspect of the problem this doesn't seem to cover nicely is the direct object transfer from child A to child B. This form of transfer is of the object-sharing kind, but I'm not sure publishing is the right term to cover it. I would be quite happy to describe all aspects of the Journal interface for making things public as publishing, though. Eben Eben Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- -Andrés ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Fri, Jul 3, 2009 at 10:42 AM, Gary C Marting...@garycmartin.com wrote: On 2 Jul 2009, at 14:47, Eben Eliason wrote: On Wed, Jul 1, 2009 at 1:42 PM, Aleksey Limalsr...@member.fsf.org wrote: But in that case we should provide possibility to mark objects that can be shared(I guess sharing all local objects by default is not a nice idea). Right. This would be essential. There's definitely some thought that needs to be done here. Scott had an interesting proposal which basically exposed the Journal (or some subset of it) as an RSS feed. This was really neat, because it meant we could build a UI for someone else's Journal in Sugar, populating it with that data, but also that these feeds could be shared globally, for anyone with an RSS reader to benefit from. That's a really powerful approach in my mind, and there is some starter code lying around as a proof of concept already! +1 to rss feed concept, makes life a lot easier in a heterogeneous environment. I'm still catching up on email so apologies if this has been mentioned already. But the UI for marking of entries as sharable does not necessarily need to be another Journal user-interface addition** In the simplest approach you could just extend the Activity Share with: my Neighbourhood control to mark a Journal entry as part of the RRS feed. Would need some The problem I see with this is that we're talking about two different kinds of sharing. Just because I want to make a picture I drew available for anyone to look at, or even make a photocopy of to scribble on, doesn't mean that I want to let them into a shared painting session so they can scribble on the original with me. This is the difference between sharing an activity with someone collaboratively, and sending them (a copy of) the resulting object. thought on wording, do you add more levels of sharing? Or do you just simplify the Share with: language language to Private, Share with: Anyone. **though I would like entries to visually show their sharing state, the buddy column hints at this but should be made explicit I do actually think that the Journal is the best place to expose this, especially since the way we plan to expose the feature in the UI is something like view my friend's Journal. I'm not sure exactly how or where that happens. Perhaps if we can abandon the checkbox for the multi-selection we can use that space for a public/private toggle of some kind. Eben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Fri, Jul 3, 2009 at 7:25 PM, Gary C Marting...@garycmartin.com wrote: On 3 Jul 2009, at 23:50, Gary C Martin wrote: On 3 Jul 2009, at 18:29, Eben Eliason wrote: On Fri, Jul 3, 2009 at 10:42 AM, Gary C Marting...@garycmartin.com wrote: On 2 Jul 2009, at 14:47, Eben Eliason wrote: On Wed, Jul 1, 2009 at 1:42 PM, Aleksey Limalsr...@member.fsf.org wrote: But in that case we should provide possibility to mark objects that can be shared(I guess sharing all local objects by default is not a nice idea). Right. This would be essential. There's definitely some thought that needs to be done here. Scott had an interesting proposal which basically exposed the Journal (or some subset of it) as an RSS feed. This was really neat, because it meant we could build a UI for someone else's Journal in Sugar, populating it with that data, but also that these feeds could be shared globally, for anyone with an RSS reader to benefit from. That's a really powerful approach in my mind, and there is some starter code lying around as a proof of concept already! +1 to rss feed concept, makes life a lot easier in a heterogeneous environment. I'm still catching up on email so apologies if this has been mentioned already. But the UI for marking of entries as sharable does not necessarily need to be another Journal user-interface addition** In the simplest approach you could just extend the Activity Share with: my Neighbourhood control to mark a Journal entry as part of the RRS feed. Would need some The problem I see with this is that we're talking about two different kinds of sharing. Just because I want to make a picture I drew available for anyone to look at, or even make a photocopy of to scribble on, doesn't mean that I want to let them into a shared painting session so they can scribble on the original with me. This is the difference between sharing an activity with someone collaboratively, and sending them (a copy of) the resulting object. Devils advocate here, so just because someone was late to the realtime party, they don't get to download an otherwise openly published piece of work that could be re-published at any time by any of the temporally lucky contributors? Downloading a Journal entry would not I think you misunderstand me, as I think I'm arguing exactly the opposite. I wouldn't want to deprive people the ability to download finished works because the sharer doesn't want to open the document up for public collaboration. The distinction is important, so that it's possible to share things with others without having to make my own documents open to collaboration. allow you in anyway to edit the remote users copy, you'd just get a snapshot downloaded to your Journal as if they had performed an equivalent Send to function. Exactly. If you conflate public vs. private states for documents with the collaboration sharing scope, every public document would also be open for public collaboration, which might not be desired, and might discourage people from sharing their output. Replying to myself, always a bad sign ;-) Use case: Darn, I missed the weekly project chat meeting, AGAIN... Oooh, Bob is still online, let me see if I can download the meeting activity entry. This might not be the best example, since by definition the chat meeting is an open collaboration, with a neighborhood (for example) sharing scope. Misc supporting argument: If you default to Journal sharing OFF and make it a new separate manual public sharing UI tick box/setting (required for I'm not necessarily stating that it should be off by default (everything private). I'm simply arguing that it should be independent of the collaboration scope. What may make sense (maybe this is what you meant?) is to default all documents which become shared with the neighborhood to public, while all others would default to private. Eben PS. I think we need to come up with some better terminology to distinguish between collaboration sharing and journal sharing. That would make this much easier to talk about. privacy), folks will rarely set it, there will be little to share from someone else's Journal so you'll rarely bother looking for something remotely. Changing the Activity sharing language from Share with: Neighbourhood to Share with: Anyone, means both synchronous and asynchronous sharing could happen, suddenly allows deployments to automatically** cross pollinate content and activities as folks move from otherwise isolated network islands. **by automatically, I mean that the sharer has not needed to be asked to provide specific access to some entry, if it already was public, then it is shared. Though this does suggest to me that we should finally be allowed to un-publicly share an entry if desired (a manual choice); and perhaps a global manual setting for deployments/users to switch of all Journal sharing. Regards, --Gary ___ Sugar
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Fri, Jul 3, 2009 at 9:52 PM, Andrés Ambroisandresambr...@gmail.com wrote: On Friday 03 July 2009 02:29:56 pm Eben Eliason wrote: On Fri, Jul 3, 2009 at 10:42 AM, Gary C Marting...@garycmartin.com wrote: On 2 Jul 2009, at 14:47, Eben Eliason wrote: On Wed, Jul 1, 2009 at 1:42 PM, Aleksey Limalsr...@member.fsf.org wrote: But in that case we should provide possibility to mark objects that can be shared(I guess sharing all local objects by default is not a nice idea). Right. This would be essential. There's definitely some thought that needs to be done here. Scott had an interesting proposal which basically exposed the Journal (or some subset of it) as an RSS feed. This was really neat, because it meant we could build a UI for someone else's Journal in Sugar, populating it with that data, but also that these feeds could be shared globally, for anyone with an RSS reader to benefit from. That's a really powerful approach in my mind, and there is some starter code lying around as a proof of concept already! +1 to rss feed concept, makes life a lot easier in a heterogeneous environment. I'm still catching up on email so apologies if this has been mentioned already. But the UI for marking of entries as sharable does not necessarily need to be another Journal user-interface addition** In the simplest approach you could just extend the Activity Share with: my Neighbourhood control to mark a Journal entry as part of the RRS feed. Would need some The problem I see with this is that we're talking about two different kinds of sharing. Just because I want to make a picture I drew available for anyone to look at, or even make a photocopy of to scribble on, doesn't mean that I want to let them into a shared painting session so they can scribble on the original with me. This is the difference between sharing an activity with someone collaboratively, and sending them (a copy of) the resulting object. thought on wording, do you add more levels of sharing? Or do you just simplify the Share with: language language to Private, Share with: Anyone. **though I would like entries to visually show their sharing state, the buddy column hints at this but should be made explicit I do actually think that the Journal is the best place to expose this, especially since the way we plan to expose the feature in the UI is something like view my friend's Journal. I'm not sure exactly how or where that happens. Perhaps if we can abandon the checkbox for the multi-selection we can use that space for a public/private toggle of some kind. How about using special tags? A Publish tag seems reasonable for this, and consistent with the fact that it could live in a publish directory an HTTP server would serve. I think it's a good idea to store these states as metadata, but I also think that we need to expose the feature visually to highlight the capability and make it easier to manage. I wouldn't want kids to have to type publish into the correct field in order to share their work. I can also imagine a tags used for starred entries and other metadata (in a general sense) used by sugar. This would make them searchable as well. Yup. I don't think this works yet, but the intent has always been to allow advanced search queries by specifying key:value pairs (as in gmail). In fact, all of the filters we support should have text equvalents, eg. cat kind:image with:alice favorite:yes (or similar). Eben Eben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- -Andrés ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
