Re: [Sugar-devel] RFC: Kill the delayed menus for good
This reminds me of a point Michael said I should mention: So, regarding the whole resume-by-default, start-new-by-default debate, is there anything wrong with the idea of having a menu pop-up at the beginning of each activity session that offers to Resume Previous and Start New options? Love, Herbert. ___ 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 14 Oct 2009, at 17:39, Eben Eliason 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!) 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. Just wanted to ping the list with a mockup and comment I've attached to a trac ticket regarding reverting the 'resume by default' home view feature: http://bugs.sugarlabs.org/ticket/1382 The direct link to the mockup image is: http://bugs.sugarlabs.org/attachment/ticket/1382/home_mockup_with_start_new_as_default.png One worry I have is that we're generating feature churn, especially if OLPC starts shipping real quantities of 0.84 in a few months... Sugar 0.82 starts new activity instances when clicking activity icons in the home view, we came up with the 'resume by default' design solution to help resolve the deluge of feedback from deployments about 'Journal spam' and teachers/kids not being able to easily enough find and resume
Re: [Sugar-devel] RFC: Kill the delayed menus for good
+1 from me! Resume by Default inhibits learning the difference between Activity and Activity Instance which is a key computer concept. Back-porting to 0.84 and 0.86 sounds great to me; is the patch simple? -Wade On Wed, Oct 28, 2009 at 2:14 PM, Gary C Martin g...@garycmartin.com wrote: On 14 Oct 2009, at 17:39, Eben Eliason 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!) 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. Just wanted to ping the list with a mockup and comment I've attached to a trac ticket regarding reverting the 'resume by default' home view feature: http://bugs.sugarlabs.org/ticket/1382 The direct link to the mockup image is: http://bugs.sugarlabs.org/attachment/ticket/1382/home_mockup_with_start_new_as_default.png One worry I have is that we're generating feature churn, especially if OLPC starts shipping real quantities of 0.84 in a few months... Sugar 0.82
Re: [Sugar-devel] RFC: Kill the delayed menus for good
2009/10/16 Eben Eliason e...@laptop.org: 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
Re: [Sugar-devel] RFC: Kill the delayed menus for good
My vote is to eliminate the delayed palettes altogether. They just get in my way, obscuring other items. The right-click option is fully satisfactory. As a senior citizen (in motor activity, similar to a child), my errant attempts to click inside a palette that disappears on me, are highly frustrating. Art Hunkins - Original Message - From: Eben Eliason e...@laptop.org To: Michael Stone mich...@laptop.org Cc: sugar-devel@lists.sugarlabs.org Sent: Wednesday, October 14, 2009 11:39 PM Subject: 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
Re: [Sugar-devel] RFC: Kill the delayed menus for good
On Sat, Oct 17, 2009 at 11:06 AM, C. Scott Ananian csc...@laptop.orgwrote: On Thu, Oct 15, 2009 at 10:34 AM, Wade Brainerd wad...@gmail.com wrote: On Thu, Oct 15, 2009 at 10:17 AM, Tomeu Vizoso to...@sugarlabs.org wrote: I'd like to put my designer hat on for a minute and offer an alternative to Bernie/Michael's patch and the current behavior: Any time the mouse hovers over a part of the screen with a delayed action, that part must immediately highlight itself. With the frame, that would be a 1px rectangle around the screen. With icons, this could be a border rectangle. An even nicer option might be to expand highlight itself to hint at what it's going to do. For example, an icon with a delayed menu could highlight itself and display a little down arrow (similar to the arrows in the new toolbars). With feedback/mockups from the design team I'd be happy to attempt this patch. I agree with Wade here -- I think the problem is not the delayed menus themselves, but that kids are not *discovering* that right-click can eliminate the delay. How are they supposed to discover that? Perhaps some thought along those lines would help. I myself found that I often waited for the delayed menu, even though I knew about right-click, because it was easier. That seems to be my choice and preference, not a priori a bad thing (even though an observer might think it a flaw). I think that I did this less often when the delay was increased, but now we're relying on imperfect memory. I agree. Even if I am right there and say right click and they have done it before so I know its discovered, its hard for the child, and I'm working with 4th graders, they are at the older end of our age range. I think its not natural/developmentally there skill for our users. Right click is also hard on a macbook with only one mouse and I think its also hard in various environments for disabilities. Of course, seeing a small child start to swear is a good indication that the user is frustrated and has not discovered any means to resolve their frustration. (Even a complexity slider has to be discoverable!) --scott ps. I've found the discussion of ideas here much more interesting than the finger-pointing. Attempts to shift responsibility (it's my patch, YOU have to prove that it's wrong -vs- it's my design, YOU have to prove that it's wrong) are productive/necessary to some degree, but a family matter you guys should take out back somewhere to hash out. We all should (IMHO) be listening much more to Daniel Drake, who seems to have the most practical experience guiding his intuitions. (Caroline, too, but I haven't her offer as specific an opinion on the issue.) pps. Perhaps this thread should have been started as a discussion of design (with working code to demonstrate), not as, here's a patch, now if you value contributors you should apply it. -- ( http://cscott.net/ ) ___ 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
Re: [Sugar-devel] RFC: Kill the delayed menus for good
On Sat, Oct 17, 2009 at 2:15 PM, Michael Stone mich...@laptop.org wrote: ps. I've found the discussion of ideas here much more interesting than the finger-pointing. Understandable; thanks for providing this feedback. Are there specific ideas that have come up in this thread other than the one that Wade supplied that you have found particularly thought-provoking? In general, revisiting the why and attempts to discover different solutions which achieve the original goals. Like Martin Dengler, I find myself convinced all over again when I revisit the original motivation. Real world feedback indicates, however, that the current behavior frustrates some users, despite best laid plans. It's obviously time to return to the why and come up with different ways to accomplish those goals. (Discussion which is simply I want X without a consideration of how this relates to the design goals is much less interesting -- I won't say useless, but it begs for someone to contextualize it and provide the missing rationale before it fits well into the conversation I would like to be having.) Attempts to shift responsibility (it's my patch, YOU have to prove that it's wrong -vs- it's my design, YOU have to prove that it's wrong) are productive/necessary to some degree, but a family matter you guys should take out back somewhere to hash out. Do you have a recommendation on where out back would be? Some other mailing list? Private conversation? If it's a truely personal matter, private email (or some physical location where you can sit down together for a beer). If it's about hashing out a philosophy of participation, then mixing it together with discussion of UI changes is not helping either conversation progress. Sometimes you can't do two things at once, but you can do them separately. I understand you to be saying that we should be listening to people with the experience necessary to have informed opinions. Is this a fair summary of your position? Not necessarily. My position is that there's an interesting UI discussion largely buried in this thread. There's also a community/contribution/patch-approval conversation which I don't have any strong opinion on. Finally, there's a meta-topic revealing some splits within the community which I do have some thoughts on. I am currently working on a(nother) strongly design-oriented bottom-up UI, and it has reminded me that such development *can* work. Having a strongly coherent user story and regular feedback from those users *is* really important. That said, unfiltered user opinions are often short-sighted. You really do need a designer role: some group of people who can keep the overall goals in mind and maintain overall direction. Some problems need evangelism, some problems need design fixes, some problems are unexpected/unresolved, some problems are won't fix (proposed feature out of scope, not relevant to target users, impossible with given resources, workaround pending further user feedback/maturity of proper fix), and some problems are just bugs. I don't think that treating all proposed code changes uniformly as bugs is the right solution. I also don't think that developers cannot put on designer hats, or vice versa. But the necessary organizational discipline seems to be missing in this thread. Separate your concerns and have separate, focused, conversations: have everyone put on designer hats and discuss the problem (some users are frustrated by context menus/some users are not as efficient as they could be/some users perceive the interface as sluggish because of intentionally-added delays), goal, and possible solutions. In another thread, put on your manager hats and figure out how to nuture contributions, organize designer roles, maintain coherence (both in code and design/vision), and maintainability (again, you should be spending as much time on design janitor work as you seem to be willing to spend on code janitorial duties). In yet another context, put on coder hats and look at the purely technical issues (in this case, how to treat patch sets which essentially orphan other blocks of code, patches which demonstrate an idea pending designer feedback, and possibly how to enable more efficient A/B testing with actual users). Finally, you can hash out whatever personal issues, grudges, or misgivings in some other context -- I've always considered actual face-to-face conferences the best way to enable reconciliation and team building, but you could also consider personal mail which says, I feel this response of yours was overly personal... or I apologize if my response seemed sharp, I thought about this more after I hit send and realized that not everyone knew XYZ which I was assuming was obvious... or whatever. I'm not helping the situation at all by opening yet another topic on this thread: the meta topic of how I feel this conversation is going. Clearly I'm not part of the solution, but you (dear readers) may be. --scott --
Re: [Sugar-devel] RFC: Kill the delayed menus for good
On Sat, Oct 17, 2009 at 11:06:32AM -0400, C. Scott Ananian wrote: I agree with Wade here -- I think the problem is not the delayed menus themselves, but that kids are not *discovering* that right-click can eliminate the delay. How are they supposed to discover that? Perhaps some thought along those lines would help. Small data point ... I only discovered the right-click in the last few days, when I derived it as a potential solution to the delay, began to think how to add it, and proceeded to test to see if anything was bound to right-click. Doh. Of course. Now I can tell the friends' kids how to remove their frustration a bit ... and I was able to add a comment to my patch set mentioning the right-click. -- James Cameron http://quozl.linux.org.au/ ___ 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 Thu, Oct 15, 2009 at 11:01:30AM +0100, Martin Dengler wrote: On Thu, Oct 15, 2009 at 06:48:31PM +1100, James Cameron wrote: I'm adding it to my list of patches that improve performance perceptions. Is this list available online somewhere? http://dev.laptop.org/~quozl/802-patches/ is for browsing http://dev.laptop.org/~quozl/802-patches.git/ is for contributors To be used on an XO, the patches must be applied as root, with / as working directory, using patch --strip 1 ... and naturally you'll need patch, but that can be copied into /usr/local/bin/ from another system. -- James Cameron http://quozl.linux.org.au/ ___ 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
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 and
Re: [Sugar-devel] RFC: Kill the delayed menus for good
For us noobs in patching, could someone make a screencast of Sugar running with this patch? Eduardo 2009/10/16 Eben Eliason e...@laptop.org: 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
Re: [Sugar-devel] RFC: Kill the delayed menus for good
I've just tried an equivalent of this patch on OLPC build 802 on an XO-1, and it feels much more responsive. It affects all mouse-over menus in Sugar. I'm adding it to my list of patches that improve performance perceptions. /usr/lib/python2.5/site-packages/sugar/graphics/ -- James Cameron http://quozl.linux.org.au/ --- palette.py.orig 2009-10-15 07:37:11.0 + +++ palette.py 2009-10-15 07:39:13.0 + @@ -209,13 +209,13 @@ self._menu_content_separator = gtk.HSeparator() -self._popup_anim = animator.Animator(.5, 10) +self._popup_anim = animator.Animator(0, 10) self._popup_anim.add(_PopupAnimation(self)) -self._secondary_anim = animator.Animator(2.0, 10) +self._secondary_anim = animator.Animator(0.0, 10) self._secondary_anim.add(_SecondaryAnimation(self)) -self._popdown_anim = animator.Animator(0.6, 10) +self._popdown_anim = animator.Animator(0, 10) self._popdown_anim.add(_PopdownAnimation(self)) # we init after initializing all of our containers ___ 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 Thu, Oct 15, 2009 at 08:58:12AM +0545, Daniel Drake wrote: It makes all menus that currently have a delay appear instantly? No, it doesn't. Try it. I think you'll like it. It is quite easy to run the cursor over the activity ring ... nothing appears until you stop for long enough. But what does appear appears without a two second delay! Consider it for deployment, Daniel. -- James Cameron http://quozl.linux.org.au/ ___ 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 Thu, Oct 15, 2009 at 03:49, Michael Stone mich...@laptop.org wrote: Tomeu wrote: On Wed, Oct 14, 2009 at 16:57, Michael Stone mich...@laptop.org wrote: Tomeu wrote: I'm more concerned about developers proposing big user experience changes because they feel it's better. Yay, more roadblocks and stereotyping! :) You shouldn't take this personal, most of Sugar contributors including me have done this in the past. humorI don't take it personally; I take it on behalf of oppressed contributors everywhere...!/humor (In other words, judging the patch by its author rather than by its text and its effects does seem to me to be a rather risky business. Your choice, though.) If you insist on thinking that I have something against you, then I will stop having this discussion with you. I'm really tired of you continuously bringing this as a problem but not hearing anyone else caring about your troubles contributing. I stand by what I said: substantial user experience changes will be considered only after discussion involving the design and deployment teams (which we are having now). This is not just for you but for anybody else that proposes patches for the modules that I maintain. Try going to a GNOME or KDE module and proposing that they accept such a patch so people can test it, they are going to laugh at your face. Maintenance is already a hard enough task, if the community thinks that a maintainer should also be accepting all patches, releasing them, packaging them, making soas spins, asking for feedback, reverting them, etc. Then I will be glad to pass maintenance to whoever is available to do these kinds of things. Regards, Tomeu I'm just saying that now might not be such a good idea any more to accept changes in the user experience without user feedback. Far better to accept the changes, get the user feedback on the changed versions, then revert the changes if they turn out to be inappropriate. Everyone will be happier. (That's my opinion, anyway.) Are you actually saying that you'd prefer either a) no patches or, b) patches that I think make the system worse? Yup, this is certainly absurd. I'm glad that we agree. If, say, Gary comes later and proposes a patch to revert yours, should I accept it in fear that I may discourage him otherwise? Yes, but in awareness rather than in fear, (though only unless you have an overriding reason not to.) Being concerned about developers proposing big user experience changes does not seem to me to meet that criterion. To my mind, overriding reasons not to include the patch is... * incorrect * illegal * an obviously bad idea * a subtly bad idea * more trouble than it's worth At best, it has been argued so far that merging the patch I showed to Bernie is a subtly bad idea because it leaves the obvious possible of refactoring of the context menu code to remove the use of the animation code unimplemented. In the middle, Eben expressed uncertainty on the basis of a specific vision and private memories. This shouldn't impede merging the patch; it should just encourage more testing and thought based on his experiences, vision, and thought experiment so that we get more data. At worst, it has been argued that merging the patch is an obviously bad idea because it was developed by a developer (me; who else was supposed to develop it?) engaged in critical dialogue with and reflection on the Sugar user experience (I do feel that it's better) via methods that I find congenial as opposed to by methods that I find prohibitively expensive. Did I miss any other positions in the debate? C'mon, I'm just asking that when substantial changes to the user experience are proposed, that we have some discussion that involves the design team and the deployments. Is this really so off? I'd call it more timid than off. Or at least inappropriately deferential to the wishes of the design team and the deployments who talk to you at the expense of receiving more contribution by making contribution more dynamic and fulfilling and therefore at the expense of exploring more possible Sugar experiences. 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? Well, trying it might be one good way to start. :) After that, shipping it in an explicit beta is another more heavyweight but nevertheless time-tested approach. You know how easy is making a spin of SoaS with such changes for people to try out, or are you saying that you want me to do this work for you? I'm saying three things; namely, that: 1. I trust that you and the other people on this list are empowered and able to make reasonable UI decisions when presented with clear alternatives, 2. Patches are an appropriate way of exchanging proposals for software modification and a good medium for discussion of those proposals, and
Re: [Sugar-devel] RFC: Kill the delayed menus for good
I take two points from this exchange: #1 User interaction changes are always subjective. Patches, requests, suggestions, etc. should not be submitted with duh as a rationale. They should be backed up with a clear rationale; better yet, hard data. #2 The Sugar UI is not sacred. There needs to be a process to collect and evaluate data, and to design and implement improvements. With changes to the user experience, writing the code is expected to be the simplest part of the process so the patch may be trivial, but acceptance may not. I could submit a patch changing the Home background color to a lovely blue; it would be trivial to apply and motivating for me, but not necessarily a good idea! The correct way to submit this patch is to file an enhancement bug, post the patch to the bug, and create a wiki page under http://wiki.sugarlabs.org/go/Features using the provided template. An improvement to this patch that would increase its likelihood of acceptance would be to make it a toggle. Even better would be to report delayed menu item clicks to a usability log server. Work with a deployment to distribute both versions randomly, analyze the results, and include that in the feature request. I'd like to put my designer hat on for a minute and offer an alternative to Bernie/Michael's patch and the current behavior: Any time the mouse hovers over a part of the screen with a delayed action, that part must immediately highlight itself. With the frame, that would be a 1px rectangle around the screen. With icons, this could be a border rectangle. Best, Wade ___ 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 Thu, Oct 15, 2009 at 14:47, Wade Brainerd wad...@gmail.com wrote: I take two points from this exchange: #1 User interaction changes are always subjective. Patches, requests, suggestions, etc. should not be submitted with duh as a rationale. They should be backed up with a clear rationale; better yet, hard data. #2 The Sugar UI is not sacred. There needs to be a process to collect and evaluate data, and to design and implement improvements. Agreed. With changes to the user experience, writing the code is expected to be the simplest part of the process so the patch may be trivial, but acceptance may not. I could submit a patch changing the Home background color to a lovely blue; it would be trivial to apply and motivating for me, but not necessarily a good idea! The correct way to submit this patch is to file an enhancement bug, post the patch to the bug, and create a wiki page under http://wiki.sugarlabs.org/go/Features using the provided template. An improvement to this patch that would increase its likelihood of acceptance would be to make it a toggle. Even better would be to report delayed menu item clicks to a usability log server. Work with a deployment to distribute both versions randomly, analyze the results, and include that in the feature request. This may be a bit too heavy process for practical purposes, I think there exists a vry wide space between what Michael asks and what you have written above. I think we would go to such a extreme only when we have already made a big change to the UI and some people wanted to revert it (for example move back the activity icons to the frame). A good middle point may be to have people who are in contact with Sugar-using children (both in the classroom and on their own) to explain how the change would affect the usage they have observed. Even better if the design team is available to explain the rationale and suggest alternatives. I'd like to put my designer hat on for a minute and offer an alternative to Bernie/Michael's patch and the current behavior: Any time the mouse hovers over a part of the screen with a delayed action, that part must immediately highlight itself. With the frame, that would be a 1px rectangle around the screen. With icons, this could be a border rectangle. I think this one would have a big impact on usability and may not be hard at all. Regards, Tomeu -- «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
Re: [Sugar-devel] RFC: Kill the delayed menus for good
Tomeu, If you insist on thinking that I have something against you, then I will stop having this discussion with you. I insist only on the reasonableness of taking you literally at your word. Naturally, I'm quite certain that you have nothing against me that you don't also have against anyone else who is as damn persnickety as I am... except when you write otherwise. I'm really tired of you continuously bringing this as a problem but not hearing anyone else caring about your troubles contributing. Three points: 1. It makes sense that you're tired of hearing about it; I'm tired of it being a problem. 2. The phrase but not hearing anyone else caring... confuses me. I can't tell whether you mean that I'm deaf to other people caring, that no one else cares, or both. Both cases seem implausible to me, but evidence is always welcome. 3. My troubles contributing are adequately controlled for by avoiding sending actual patches. You saw this one only because Bernie said that he liked the effect when I showed it to him and because I told him that if he liked it, then he should recommend that others try it. (Actually, you might have seen it earlier when I mentioned it to you in IRC a few weeks ago, but I can easily understand how a single line of IRC traffic is easy to miss.) I stand by what I said: substantial user experience changes will be considered only after discussion involving the design and deployment teams (which we are having now). This is not just for you but for anybody else that proposes patches for the modules that I maintain. I understand but continue to question the usefulness of the decision given its obvious overhead and consequences. Enjoy the fruits of your choice. Try going to a GNOME or KDE module and proposing that they accept such a patch so people can test it, they are going to laugh at your face. Sugar is not GNOME or KDE (nor the kernel, where experience demonstrates that the pattern you refer to is actually fairly common). Consequently, we should find out what's right for Sugar. There's nothing wrong with you having one position which is different from mine. Maintenance is already a hard enough task, if the community thinks that a maintainer should also be accepting all patches, releasing them, packaging them, making soas spins, asking for feedback, reverting them, etc. Then I will be glad to pass maintenance to whoever is available to do these kinds of things. If you find such a person, then please consider it -- I think Sugar would benefit greatly from having a maintainership community with the resources to do those things in that order, as I suggested in more detail in the remaining part of my last email to which you didn't reply. Regards, Michael ___ 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
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. 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. 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. 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 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. 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? So what you're saying is that you want to force children to use the system in a way that you just said is contrary to what THEY actually want to do. 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. Many kids have motor skills, and the ones that don't initially are remarkably good (being kids) at developing motor skills that they don't yet have. Many kids also read. In fact, let's cut into some real deep philosophy stuff here... The idea that the XO laptop is mainly for kids who can't read is completely bogus. Now, maybe you're thinking of other children when you say this, but I prefer to first consider the main existing userbase. Laptops which have Sugar installed on them are primarily located in schools and are used for education. It is kind of ridiculous to say Well, you don't actually need to know how to read to use the laptops, so we should make the interface not require reading. when the truth is that, for most activities that have any educational merit, you DO need to read and you need to read things significantly more complicated than activity names. Most of the people who use Sugar for most of the time WILL know how to read. Daniel Drake wrote: It makes all menus that currently have a delay appear instantly? Not even close. On the XO sitting next to me it still feels like over a second. There appears to actually be ANOTHER delay somewhere that was not modified at all, because the UI takes the same amount of time to respond with the change on both an XO and on a significantly more powerful laptop. What is noticable, however, is that it just doesn't feel like things are craaw-aww-aawwwaaawww-ling (ling) after the change, because before the user was met with a multi-stage, phased delay, whereas now the delay is brief and only up front. If you haven't yet, you really need to at least try it. All of this I don't like it, but I haven't actually tried it stuff is just unhelpful. Sincerely, Avi Kelman ___ 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 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
2009/10/15 James Cameron qu...@laptop.org: No, it doesn't. Try it. I think you'll like it. It is quite easy to run the cursor over the activity ring ... nothing appears until you stop for long enough. But what does appear appears without a two second delay! OK then, that sounds a lot better. I'm surprised that this point wasn't raised earlier. Given that this thread is largely about process, let me throw in one more point then: all patches should be accompanied with a good description of the change that they actually make :) Daniel ___ 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
El Fri, 16-10-2009 a las 09:44 +0545, Daniel Drake escribió: OK then, that sounds a lot better. I'm surprised that this point wasn't raised earlier. Given that this thread is largely about process, let me throw in one more point then: all patches should be accompanied with a good description of the change that they actually make :) +1, but in this case this was just an RFC meant to let people test the new behavior and comment on it. Surprisingly, a lot of feedback came from people who had not actually tried the patch or even *looked* at it! Lack of expertise is not a good excuse as we claim that even children could make changes to Sugar. Here's Michael's patch again (attached below). As can be seen, it's really as trivial as changing just 3 bytes in two files (it's really 3 changed bytes and 1 added byte, but it could be done in just 3 moves :-). One could also edit the files in-place from a SoaS or XO image: vi /lib/python2.6/site-packages/sugar/graphics/palette.py +106 vi /lib/python2.6/site-packages/sugar/graphics/palettewindow.py +151 From: Michael Stone mich...@laptop.org Date: Mon, 14 Sep 2009 22:33:12 -0400 Subject: Make various palette animations happen more quickly. --- src/sugar/graphics/palette.py |2 +- src/sugar/graphics/palettewindow.py |4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/sugar/graphics/palette.py b/src/sugar/graphics/palette.py --- a/src/sugar/graphics/palette.py +++ b/src/sugar/graphics/palette.py @@ -103,7 +103,7 @@ class Palette(PaletteWindow): self._menu_content_separator = gtk.HSeparator() -self._secondary_anim = animator.Animator(2.0, 10) +self._secondary_anim = animator.Animator(0.0, 10) self._secondary_anim.add(_SecondaryAnimation(self)) # we init after initializing all of our containers diff --git a/src/sugar/graphics/palettewindow.py b/src/sugar/graphics/palettewindow.py --- a/src/sugar/graphics/palettewindow.py +++ b/src/sugar/graphics/palettewindow.py @@ -148,10 +148,10 @@ class PaletteWindow(gtk.Window): self._up = False self._old_alloc = None -self._popup_anim = animator.Animator(.5, 10) +self._popup_anim = animator.Animator(0.0, 10) self._popup_anim.add(_PopupAnimation(self)) -self._popdown_anim = animator.Animator(0.6, 10) +self._popdown_anim = animator.Animator(0.0, 10) self._popdown_anim.add(_PopdownAnimation(self)) gobject.GObject.__init__(self, **kwargs) -- 1.5.6.5 -- // 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
Re: [Sugar-devel] RFC: Kill the delayed menus for good
On Tue, Oct 13, 2009 at 03:40, Bernie Innocenti ber...@codewiz.org wrote: El Mon, 12-10-2009 a las 22:36 -0400, Bernie Innocenti escribió: 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!) BTW, Michael and I have a small disagreement on how a maintainer should react to the present patch. From a purely functional PoV, this patch is short, correct and low impact. Yeah, but... who's ever going to clean up after it if we do not demand the cleanup to be merged atomically with the patch that opens the need for it? Once the patch is in, the maintainer would no longer have a stick to brandish while saying now eat your veggies!. (Michael replies: This is a flawed position because it leads to absurd conclusions. More specifically, it actively discourages the current contributor from submitting more patches by denying the satisfaction of seeing their existing patch merged, delays the deferral of a correct and believable patch that introduces behavior you yourself describe as 'desirable' and, last but not least, misses an opportunity to involve inexperienced contributors by providing appropriate on-ramp bugs like the proposed refactoring.) 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? Thanks, Tomeu -- «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
Re: [Sugar-devel] RFC: Kill the delayed menus for good
A word of initial warning: please turn on your sense of the absurd before reading. This response is written with a deep sense of amusement, rather than angst. Tomeu wrote: I'm more concerned about developers proposing big user experience changes because they feel it's better. Yay, more roadblocks and stereotyping! :) Are you actually saying that you'd prefer either a) no patches or, b) patches that I think make the system worse? 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? Well, trying it might be one good way to start. :) After that, shipping it in an explicit beta is another more heavyweight but nevertheless time-tested approach. Failing that option, you likely need to find some product specialists. ... For what it's worth, I do view this patch as a UI bandaid to the underlying problem that hover-to-click-somewhere-else is the wrong UI affordance for the home screen to use in supporting discovery of and access to variant or associated behaviors. The patch is, however, still a big improvement that is available today. Now, as for what better look like: treat each view has having a primary layout algorithm for Sugar-level UI actions. This algorithm should effectively arrange logically related groups of capabilities as determined by metadata attached to the capabilities and as determined by the current filtering criteria for the view. In actual activities, this layout algorithm is the new toolbar approach. The filtering criteria are hover-or-click on an expandable toolbar item. In the circle view, I'd like to see the layout algorithm expanded to lay out arcs of smaller option icons each with the same prelighting and saturation behavior as partial halos around the exterior perimeter of the activity icons. Naturally, there are some obvious interesting extensions involving zoom effects and more subtle saturation behaviors. Lastly, it seems to me that a similar approach might also be effective in the mesh view and around the central XO-figure. Kind regards, Michael ___ 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 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. Regards, Simon ___ 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 7:14 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Tue, Oct 13, 2009 at 03:40, Bernie Innocenti ber...@codewiz.org wrote: El Mon, 12-10-2009 a las 22:36 -0400, Bernie Innocenti escribió: 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!) BTW, Michael and I have a small disagreement on how a maintainer should react to the present patch. From a purely functional PoV, this patch is short, correct and low impact. Yeah, but... who's ever going to clean up after it if we do not demand the cleanup to be merged atomically with the patch that opens the need for it? Once the patch is in, the maintainer would no longer have a stick to brandish while saying now eat your veggies!. (Michael replies: This is a flawed position because it leads to absurd conclusions. More specifically, it actively discourages the current contributor from submitting more patches by denying the satisfaction of seeing their existing patch merged, delays the deferral of a correct and believable patch that introduces behavior you yourself describe as 'desirable' and, last but not least, misses an opportunity to involve inexperienced contributors by providing appropriate on-ramp bugs like the proposed refactoring.) 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? People could take both versions to a group of kids and video how it goes. Thanks, Tomeu -- «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 -- 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
Re: [Sugar-devel] RFC: Kill the delayed menus for good
In marketing parlance, these would be called focus groups and are a very effective and quick way to get feedback. The group I did at my kids' school last June (http://lists.sugarlabs.org/archive/marketing/2009-June/001625.html) immediately showed for example the problems kids had with quitting Activities. Sean On Wed, Oct 14, 2009 at 6:15 PM, Caroline Meeks solutiongr...@gmail.com wrote: On Wed, Oct 14, 2009 at 7:14 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Tue, Oct 13, 2009 at 03:40, Bernie Innocenti ber...@codewiz.org wrote: El Mon, 12-10-2009 a las 22:36 -0400, Bernie Innocenti escribió: 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!) BTW, Michael and I have a small disagreement on how a maintainer should react to the present patch. From a purely functional PoV, this patch is short, correct and low impact. Yeah, but... who's ever going to clean up after it if we do not demand the cleanup to be merged atomically with the patch that opens the need for it? Once the patch is in, the maintainer would no longer have a stick to brandish while saying now eat your veggies!. (Michael replies: This is a flawed position because it leads to absurd conclusions. More specifically, it actively discourages the current contributor from submitting more patches by denying the satisfaction of seeing their existing patch merged, delays the deferral of a correct and believable patch that introduces behavior you yourself describe as 'desirable' and, last but not least, misses an opportunity to involve inexperienced contributors by providing appropriate on-ramp bugs like the proposed refactoring.) 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? People could take both versions to a group of kids and video how it goes. Thanks, Tomeu -- «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 -- 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] 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 16:57, Michael Stone mich...@laptop.org wrote: A word of initial warning: please turn on your sense of the absurd before reading. This response is written with a deep sense of amusement, rather than angst. Tomeu wrote: I'm more concerned about developers proposing big user experience changes because they feel it's better. Yay, more roadblocks and stereotyping! :) You shouldn't take this personal, most of Sugar contributors including me have done this in the past. I'm just saying that now might not be such a good idea any more to accept changes in the user experience without user feedback. Are you actually saying that you'd prefer either a) no patches or, b) patches that I think make the system worse? Yup, this is certainly absurd. If, say, Gary comes later and proposes a patch to revert yours, should I accept it in fear that I may discourage him otherwise? C'mon, I'm just asking that when substantial changes to the user experience are proposed, that we have some discussion that involves the design team and the deployments. Is this really so off? 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? Well, trying it might be one good way to start. :) After that, shipping it in an explicit beta is another more heavyweight but nevertheless time-tested approach. You know how easy is making a spin of SoaS with such changes for people to try out, or are you saying that you want me to do this work for you? Failing that option, you likely need to find some product specialists. ... For what it's worth, I do view this patch as a UI bandaid to the underlying problem that hover-to-click-somewhere-else is the wrong UI affordance for the home screen to use in supporting discovery of and access to variant or associated behaviors. The patch is, however, still a big improvement that is available today. Now, as for what better look like: treat each view has having a primary layout algorithm for Sugar-level UI actions. This algorithm should effectively arrange logically related groups of capabilities as determined by metadata attached to the capabilities and as determined by the current filtering criteria for the view. In actual activities, this layout algorithm is the new toolbar approach. The filtering criteria are hover-or-click on an expandable toolbar item. In the circle view, I'd like to see the layout algorithm expanded to lay out arcs of smaller option icons each with the same prelighting and saturation behavior as partial halos around the exterior perimeter of the activity icons. Naturally, there are some obvious interesting extensions involving zoom effects and more subtle saturation behaviors. Lastly, it seems to me that a similar approach might also be effective in the mesh view and around the central XO-figure. I'm having trouble getting your proposal, maybe some mockups would help. Regards, Tomeu -- «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
Re: [Sugar-devel] RFC: Kill the delayed menus for good
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. 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. 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. 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. 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. Just for fun, I might suggest an alternate possibility which actually decreases the discoverability of the secondary palette. Not my kind of fun. 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. I don't like to hear children divided into advanced and non-advanced that way. If we get a series of lesson plans together on all of the known non-discoverable elements of Sugar, we should be able to get this difference down to two or three weeks max. Then we can talk about advanced children being the ones who have developed skill in what an Activity is for, not in knobs and blinkenlights. 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 want to know what is in the children's minds. I think starting from home, with the
Re: [Sugar-devel] RFC: Kill the delayed menus for good
El Wed, 14-10-2009 a las 12:15 -0400, Caroline Meeks escribió: People could take both versions to a group of kids and video how it goes. When are you going to be at the GPA? Next time I could come along, apply the patch before the kids start using the machines, and then we could interview them at the end of the day about their experience. Or -- if we were evil enough -- we could patch only half of the stations and see which group performs better ;-) -- // 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
Re: [Sugar-devel] RFC: Kill the delayed menus for good
On Wed, Oct 14, 2009 at 1:50 PM, Bernie Innocenti ber...@codewiz.orgwrote: El Wed, 14-10-2009 a las 12:15 -0400, Caroline Meeks escribió: People could take both versions to a group of kids and video how it goes. When are you going to be at the GPA? Next time I could come along, apply the patch before the kids start using the machines, and then we could interview them at the end of the day about their experience. Or -- if we were evil enough -- we could patch only half of the stations and see which group performs better ;-) they all have their own sticks so that might not be quite so easy. Also I don't want to do it during classroom time. We hope to start an afterschool session on Sugar on Fridays in a couple of weeks. Want to help? I think once we've done that for a few times we might be able to ask to borrow some kids who have yet to use Sugar some afternoon when they are in after-school. Give half of them one kind of stick and half another in the GPA computer lab. Realistically, I think it will be about a month before I could set that up, just in terms of how many new requests I can give the school at once. There is also a club at Harvard using XOs in a Boston after school program. I'm not sure where they are in their process but they might be able to provide a test bed on XOs. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- 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
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 on
Re: [Sugar-devel] RFC: Kill the delayed menus for good
Michael Stone wrote: In the circle view, I'd like to see the layout algorithm expanded to lay out arcs of smaller option icons each with the same prelighting and saturation behavior as partial halos around the exterior perimeter of the activity icons. It took me a while to get this, but now that I understand it, I like it. The basic idea is to make the current palette appear with no delay on rollover, but not directly under the cursor. The user is not dissuaded from clicking on the primary icon, which remains accessible, but the secondary options are also immediately visible. The obvious problem with this is that the palette may cover another nearby icon, preventing the user from accessing it. A simple solution, in the circle view, would be to make the palette always pop out, away from the center. Michael proposes a more aesthetic solution, changing the geometry of the palettes to curve around the outside of the circle. signature.asc Description: OpenPGP digital signature ___ 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 12:14:57PM +0100, Tomeu Vizoso wrote: On Tue, Oct 13, 2009 at 03:40, Bernie Innocenti ber...@codewiz.org wrote: El Mon, 12-10-2009 a las 22:36 -0400, Bernie Innocenti escribió: 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. 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? From [1]: Also the context menu, that appears when hovering for a moment over an icon, providing some settings or features, irritated at least five children more than it was supportive. Only two children used the context menu of the home screen-icons to identify the activity, because the name of the activity is displayed on top of the menu. [The children] were partially bothered [by the context menu-function] and one girl even groaned every time the menu appears, because she did not want it to. Eben's justification of popup-menus[2] (which I alway re-buy into everytime I read it) is perhaps not being absorbed by Activity developers? Perhaps with a bit of developer elbow-grease we can eliminate the crutch of the popup-menu from every (Fructose) Activity? Thanks, Tomeu Martin 1. http://dimeb.informatik.uni-bremen.de/documents/Sugar-Not_necessarily_unhealthy.pdf My favourite use out of context for bashing-the-UI-design quote is: Every-time the Frame appeared, which happened mostly unintentional, the children were irritated and one girl even [got] a little bit angry and started to swear. 2. http://lists.sugarlabs.org/archive/sugar-devel/2009-October/020209.html pgpKi7DFrbw6q.pgp Description: PGP signature ___ 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
Simon wrote: On 10/13/2009 04:36 AM, Bernie Innocenti wrote: I'm loving how the menus suddenly are now snappy and responsive. From: Michael Stone ... Subject: Make various palette animations happen more quickly. ... Can you describe what the patch will change from the user point of view? Of course I can. In fact, I believe that Bernie and I already did, in the lines of your message that I quoted above. Do you actually find these lines to be obscure? (I inquire most particularly because I'm nearly certain that you could have learned the user-visible effect of the patch more quickly and more easily by trying out the change yourself than by asking. Maybe you had a more complex goal in mind than simply learning the nature of the user-visible change which justifies the additional delay and round-trips that your request incurs?) Is this to get rid of the delayed build up of palettes when hovering over icons? Yes, this is the purpose of setting the length of the build-up animation to be 0.0 seconds. The delay is on purpose. Of course it is. Unfortunately, that does not make it good. Now, after trying out the patched version vs. the unpatched version, do you actually find that you prefer the current behavior? Kind regards, Michael ___ 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 4:42 PM, Michael Stone mich...@laptop.org wrote: Simon wrote: On 10/13/2009 04:36 AM, Bernie Innocenti wrote: I'm loving how the menus suddenly are now snappy and responsive. From: Michael Stone ... Subject: Make various palette animations happen more quickly. ... Can you describe what the patch will change from the user point of view? Of course I can. In fact, I believe that Bernie and I already did, in the lines of your message that I quoted above. Do you actually find these lines to be obscure? (I inquire most particularly because I'm nearly certain that you could have learned the user-visible effect of the patch more quickly and more easily by trying out the change yourself than by asking. Maybe you had a more complex goal in mind than simply learning the nature of the user-visible change which justifies the additional delay and round-trips that your request incurs?) Is this to get rid of the delayed build up of palettes when hovering over icons? Yes, this is the purpose of setting the length of the build-up animation to be 0.0 seconds. The delay is on purpose. Of course it is. Unfortunately, that does not make it good. Now, after trying out the patched version vs. the unpatched version, do you actually find that you prefer the current behavior? Kind regards, Michael ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel Can the delay of showing the right-click menu be user configurable via control panel just like the frame sensitivity? I've seen both use cases: right click and hover to access the menu. Sameer ___ 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
Tomeu wrote: On Wed, Oct 14, 2009 at 16:57, Michael Stone mich...@laptop.org wrote: Tomeu wrote: I'm more concerned about developers proposing big user experience changes because they feel it's better. Yay, more roadblocks and stereotyping! :) You shouldn't take this personal, most of Sugar contributors including me have done this in the past. humorI don't take it personally; I take it on behalf of oppressed contributors everywhere...!/humor (In other words, judging the patch by its author rather than by its text and its effects does seem to me to be a rather risky business. Your choice, though.) I'm just saying that now might not be such a good idea any more to accept changes in the user experience without user feedback. Far better to accept the changes, get the user feedback on the changed versions, then revert the changes if they turn out to be inappropriate. Everyone will be happier. (That's my opinion, anyway.) Are you actually saying that you'd prefer either a) no patches or, b) patches that I think make the system worse? Yup, this is certainly absurd. I'm glad that we agree. If, say, Gary comes later and proposes a patch to revert yours, should I accept it in fear that I may discourage him otherwise? Yes, but in awareness rather than in fear, (though only unless you have an overriding reason not to.) Being concerned about developers proposing big user experience changes does not seem to me to meet that criterion. To my mind, overriding reasons not to include the patch is... * incorrect * illegal * an obviously bad idea * a subtly bad idea * more trouble than it's worth At best, it has been argued so far that merging the patch I showed to Bernie is a subtly bad idea because it leaves the obvious possible of refactoring of the context menu code to remove the use of the animation code unimplemented. In the middle, Eben expressed uncertainty on the basis of a specific vision and private memories. This shouldn't impede merging the patch; it should just encourage more testing and thought based on his experiences, vision, and thought experiment so that we get more data. At worst, it has been argued that merging the patch is an obviously bad idea because it was developed by a developer (me; who else was supposed to develop it?) engaged in critical dialogue with and reflection on the Sugar user experience (I do feel that it's better) via methods that I find congenial as opposed to by methods that I find prohibitively expensive. Did I miss any other positions in the debate? C'mon, I'm just asking that when substantial changes to the user experience are proposed, that we have some discussion that involves the design team and the deployments. Is this really so off? I'd call it more timid than off. Or at least inappropriately deferential to the wishes of the design team and the deployments who talk to you at the expense of receiving more contribution by making contribution more dynamic and fulfilling and therefore at the expense of exploring more possible Sugar experiences. 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? Well, trying it might be one good way to start. :) After that, shipping it in an explicit beta is another more heavyweight but nevertheless time-tested approach. You know how easy is making a spin of SoaS with such changes for people to try out, or are you saying that you want me to do this work for you? I'm saying three things; namely, that: 1. I trust that you and the other people on this list are empowered and able to make reasonable UI decisions when presented with clear alternatives, 2. Patches are an appropriate way of exchanging proposals for software modification and a good medium for discussion of those proposals, and 3. Applying a 6-line patch to a jhbuild root, to a Sugar chroot produced with my scripts, or to a live Sugar install is a hell of a lot easier (and more valuable to know how to do) than my cooking up a SoaS image just for interested people to try out said patch. (For the record, I'm more sympathetic to the SoaS argument with rainbow stuff but the rainbowish work that I'm doing at the moment lies in the area of network isolation and community-building [c.f. my new playground at sandboxing.org] rather than in Sugar integration.) Now, as for what better look like: ... I'm having trouble getting your proposal, maybe some mockups would help. A fair request, but one that is probably doomed to wait until someone with graphics and/or animation skills comes along to help me transform my words into pictures and movies. (Interested folks should please contact me; I'd be very happy to work with you on obtaining such visual materials.) Regards, Michael P.S. - For even more humor, count how many words have gone into this thread so far in
Re: [Sugar-devel] RFC: Kill the delayed menus for good
2009/10/13 Bernie Innocenti ber...@codewiz.org: 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. I haven't tried it, and your mail also lacks an explicit explanation of what your patch actually does, but based on the hints you have provided, : It makes all menus that currently have a delay appear instantly? I don't like the idea, as I think that the delay has influenced Sugar's UI design quite heavily. For example, a user is on the home screen with ring view enabled, and the mouse cursor is on the left side of the screen. The user wants to shut down the XO. He moves the cursor towards the XO figure in the middle of the screen, but while doing so passes over an activity icon in the ring. The menu immediately appears, completely obscuring the XO figure that he was going to click on. Daniel ___ 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
Daniel wrote: 2009/10/13 Bernie Innocenti ber...@codewiz.org: 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. I haven't tried it, and your mail also lacks an explicit explanation of what your patch actually does, but based on the hints you have provided, : It makes all menus that currently have a delay appear instantly? It makes the menus appear and disappear much more quickly by setting the length of their animations to be 0.0 seconds, thereby simulating snappy and responsive. Whether or not their appearance and disappearance is instantaneous depends on your processor; Python and GTK are still surprisingly slow. I don't like the idea, as I think that the delay has influenced Sugar's UI design quite heavily. You're obviously entitled to your opinion. I'd still appreciate it if you tried out the patch. For example, a user is on the home screen with ring view enabled, and the mouse cursor is on the left side of the screen. The user wants to shut down the XO. He moves the cursor towards the XO figure in the middle of the screen, but while doing so passes over an activity icon in the ring. The menu immediately appears, completely obscuring the XO figure that he was going to click on. I have actually tried to produce this behavior. In practice, I can't find anyway to make it frustrating because the menus also *disappear* quickly when the cursor leaves their boundary. (I would nevertheless be interested in hearing about actual experience reports from frustrated users.) Regards, Michael ___ 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
2009/10/15 Michael Stone mich...@laptop.org: the menus also *disappear* quickly when the cursor leaves their boundary. In the field I actually have considered on various occasions doing the opposite. I've seen many children struggle to keep the mouse inside the menu while navigating to the item they want to click on, and having 1 or 2 more seconds to reposition the mouse before the menu disappears might help a lot. (of course it might bring in some other undesirable effects, these are just some initial thoughts from field frustration) Daniel ___ 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 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] RFC: Kill the delayed menus for good
Eben wrote: 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. Do I correctly understand that a) when you wrote we should definitely get feedback up above, you actually meant YOU should get feedback and bring it to me. and that b) when you wrote I definitely want to make sure that we make such a change for the right reasons you were not, in fact, considering does it feel good to use? to be a critical part of the right reasons? I have no itch. You don't need to have an itch to try to help someone else accomplish a reasonable goal that you do not actively oppose. That's called Encouraging Contribution. 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. Which of the following do you disagree with? a) visible but unobtrusive is a lower floor than hover b) visible but unobtrusive is a higher ceiling than hover c) visible but unobtrusive is provides increasing levels of detail better than hover d) other objection It's better if you're one who frequently has needs for the additional complexity. I'm actually claiming that it's uniformly better: hover without a lock open as is available in the new toolbars is Just A Bad Idea, particularly as we see more devices with touchscreens. It's arguably not if you use only (or mostly) primary actions. Having the sub actions be always available in the same field of view but unobtrusive, e.g. by means of effective use of color, contrast, and size just seems like a better solution to me. I'm sorry that I don't have the code or animations necessary to demonstrate this today. However, that lack should in no way alter our consideration of the current patch. 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. It's one choice, but it's a bad one. We can do better. Also, it is not a complexity slider, most notably because it is not visible in the same field of view as the interface it controls. Remember -- comparisons should be made in a fixed visual field, not across multi-second long gulfs of time, cursor positioning, and fine motor control. You didn't respond to this principle. Do you accept it or feel that it misses some important cases? 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? As I wrote to Daniel, my experience was that the overall increased responsiveness of the UI more than made up for any annoyance that I experienced as a result of its occasionally poor layout choices.
[Sugar-devel] RFC: Kill the delayed menus for good
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 Stone mich...@laptop.org Date: Mon, 14 Sep 2009 22:33:12 -0400 Subject: Make various palette animations happen more quickly. --- src/sugar/graphics/palette.py |2 +- src/sugar/graphics/palettewindow.py |4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/sugar/graphics/palette.py b/src/sugar/graphics/palette.py index bb2b605..466edef 100644 --- a/src/sugar/graphics/palette.py +++ b/src/sugar/graphics/palette.py @@ -103,7 +103,7 @@ class Palette(PaletteWindow): self._menu_content_separator = gtk.HSeparator() -self._secondary_anim = animator.Animator(2.0, 10) +self._secondary_anim = animator.Animator(0.0, 10) self._secondary_anim.add(_SecondaryAnimation(self)) # we init after initializing all of our containers diff --git a/src/sugar/graphics/palettewindow.py b/src/sugar/graphics/palettewindow.py index 3049f55..4bc07e2 100644 --- a/src/sugar/graphics/palettewindow.py +++ b/src/sugar/graphics/palettewindow.py @@ -148,10 +148,10 @@ class PaletteWindow(gtk.Window): self._up = False self._old_alloc = None -self._popup_anim = animator.Animator(.5, 10) +self._popup_anim = animator.Animator(0.0, 10) self._popup_anim.add(_PopupAnimation(self)) -self._popdown_anim = animator.Animator(0.6, 10) +self._popdown_anim = animator.Animator(0.0, 10) self._popdown_anim.add(_PopdownAnimation(self)) gobject.GObject.__init__(self, **kwargs) -- 1.5.6.5 -- // 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
Re: [Sugar-devel] RFC: Kill the delayed menus for good
On Mon, Oct 12, 2009 at 9:40 PM, Bernie Innocenti ber...@codewiz.org wrote: El Mon, 12-10-2009 a las 22:36 -0400, Bernie Innocenti escribió: 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!) BTW, Michael and I have a small disagreement on how a maintainer should react to the present patch. From a purely functional PoV, this patch is short, correct and low impact. Yeah, but... who's ever going to clean up after it if we do not demand the cleanup to be merged atomically with the patch that opens the need for it? Once the patch is in, the maintainer would no longer have a stick to brandish while saying now eat your veggies!. (Michael replies: This is a flawed position because it leads to absurd conclusions. More specifically, it actively discourages the current contributor from submitting more patches by denying the satisfaction of seeing their existing patch merged, delays the deferral of a correct and believable patch that introduces behavior you yourself describe as 'desirable' and, last but not least, misses an opportunity to involve inexperienced contributors by providing appropriate on-ramp bugs like the proposed refactoring.) -- Bernie Michael The requirement for patches which are clean, correct, and adhere to SL coding standards is orthogonalization to either sticks or carrots. The requirement exists because code is expensive to maintain. The decision to accept code is up to the maintainer. This is yet another example of the upstream-downstream tension. In this case, the developer wants early and often while the maintainer wants stable and seldom. It is interesting to see how the definitions of early and often and stable and seldom shift as we move up and down the stream. david ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
