Re: [Sugar-devel] ribbon, right-click, button bars (was: RFC: Kill the delayed menus for good)
On Tue, Oct 20, 2009 at 04:40:28PM -0400, Albert Cahalan wrote: > It's not that they don't understand. Their fingers land in the wrong > spot. They may click right in the middle, hitting both buttons at > once. I've seen this. I've a theory. In other life experiences, kids often have to press at a spot that gives tactile feedback prior to the press. Across the front of the XO those spots include the left edge of the left button, the right edge of the right button, *and* the interface between the two. Close your eyes, clear your mind, and run your finger along. -- 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] ribbon, right-click, button bars (was: RFC: Kill the delayed menus for good)
On Tue, Oct 20, 2009 at 4:19 PM, Eben Eliason wrote: > On Tue, Oct 20, 2009 at 4:08 PM, Albert Cahalan wrote: >> Eben Eliason writes: >>> Another possibility would be to educate children about right click >>> somehow. >> >> On the one hand, I think it's really important to do this. Besides >> the human-compatibility issue and the extra expressive power, I think >> using a second button will help to develop the mind a bit. (you're not >> just grabbing or poking when you click; you're performing an action >> that could be determined by which button you click) >> >> On the other hand, I think both buttons should be the left button >> by default. Kids have trouble hitting the correct button. Button >> mistakes should not be something kids face from the moment go. > > Yup. The hardware design was done before a UI team was organized at > OLPC. One of the first suggestions, though it was already too late, > was to limit the hardware to one button. The hardware needs two buttons so that it can support the kid as he grows older. The only button issue I can see is that there is no space between the buttons; there should be a gap or the buttons should be on opposite sides of the track pad. (not that a track pad is OK with filthy kid fingers) The software should map the buttons together by default. Here's a config proposal: By default, the buttons are mapped together and there are hover menus. There is a config switch that enables distinct buttons and changes hover menus to right-click menus. Here is an alternate default: The right button shows an animation of clicking on the left button or similar, correcting the user. (this is currently the default for Tux Paint; an adult is expected to change to both-are-left for 2-year-old kids) > provide a more traditional right-click functionality both because it > did provide a way to offer more contextual actions in a manner > consistent with other interfaces that already exist, and because we > thought it could actually be perplexing to have two buttons that > always appeared to do the same thing. If that's proving problematic > for children in practice, we could make a change there. I hadn't heard > much on that particular issue, so I don't know how common (or > persistent) it is. It's not that they don't understand. Their fingers land in the wrong spot. They may click right in the middle, hitting both buttons at once. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ribbon, right-click, button bars (was: RFC: Kill the delayed menus for good)
On Tue, Oct 20, 2009 at 4:08 PM, Albert Cahalan wrote: > Eben Eliason writes: > >> palettes, we aimed to reduce accidental invocation >> of them without entirely eliminating discovery by increasing the >> delay. > ... >> I'm more worried about immediately revealing of all secondary >> actions, which pull attention from the more efficient manner in >> which basic actions can be performed - namely, clicking on the >> big icons. >> >> If we can do this in a manner which doesn't distract from the >> primary interaction methods and encourage inefficient paths >> through the UI, that would be great. > > I believe this was first solved by Kid Pix, a few decades ago. > One button bar swaps out another button bar. > > Microsoft's ribbon looks like the same thing, though I've never > used it so I can't say for sure. > > Tux Paint certainly uses this model. In that case, it works fine > for kids **way** below sugar's target age. (smart 2-year-old or > regular 4-year-old for sure, possibly younger) Yeah. This is very similar to the now implemented redesign of the toolbar system for activities, which feedback has indicated is a huge improvement. However, it doesn't instantly solve the issue for freely positioned UI elements, such as people and activities within the various zoom levels. There may be a variation on the technique that could work in these contexts, of course, and some interesting possibilities have already been suggested. >> Another possibility would be to educate children about right click >> somehow. > > On the one hand, I think it's really important to do this. Besides > the human-compatibility issue and the extra expressive power, I think > using a second button will help to develop the mind a bit. (you're not > just grabbing or poking when you click; you're performing an action > that could be determined by which button you click) > > On the other hand, I think both buttons should be the left button > by default. Kids have trouble hitting the correct button. Button > mistakes should not be something kids face from the moment go. Yup. The hardware design was done before a UI team was organized at OLPC. One of the first suggestions, though it was already too late, was to limit the hardware to one button. Since we didn't have the opportunity to change that, we opted to provide a more traditional right-click functionality both because it did provide a way to offer more contextual actions in a manner consistent with other interfaces that already exist, and because we thought it could actually be perplexing to have two buttons that always appeared to do the same thing. If that's proving problematic for children in practice, we could make a change there. I hadn't heard much on that particular issue, so I don't know how common (or persistent) it is. >> Perhaps, as suggested by Wade, we could allude to the availability >> of more information immediately on hover, and perhaps even try making >> the right button the only means of invoking the secondary actions. >> This does work today, but the lack of discoverability is a definite >> problem. > > It's no less discoverable than the left button. Right-click menus True. > need to work two ways though: > > a. Press and hold down right button, move, release > b. Click (press and release) right button, move, click either button Agreed. This would be a good improvement to the behavior. Eben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] ribbon, right-click, button bars (was: RFC: Kill the delayed menus for good)
Eben Eliason writes: > palettes, we aimed to reduce accidental invocation > of them without entirely eliminating discovery by increasing the > delay. ... > I'm more worried about immediately revealing of all secondary > actions, which pull attention from the more efficient manner in > which basic actions can be performed - namely, clicking on the > big icons. > > If we can do this in a manner which doesn't distract from the > primary interaction methods and encourage inefficient paths > through the UI, that would be great. I believe this was first solved by Kid Pix, a few decades ago. One button bar swaps out another button bar. Microsoft's ribbon looks like the same thing, though I've never used it so I can't say for sure. Tux Paint certainly uses this model. In that case, it works fine for kids **way** below sugar's target age. (smart 2-year-old or regular 4-year-old for sure, possibly younger) > Another possibility would be to educate children about right click > somehow. On the one hand, I think it's really important to do this. Besides the human-compatibility issue and the extra expressive power, I think using a second button will help to develop the mind a bit. (you're not just grabbing or poking when you click; you're performing an action that could be determined by which button you click) On the other hand, I think both buttons should be the left button by default. Kids have trouble hitting the correct button. Button mistakes should not be something kids face from the moment go. > Perhaps, as suggested by Wade, we could allude to the availability > of more information immediately on hover, and perhaps even try making > the right button the only means of invoking the secondary actions. > This does work today, but the lack of discoverability is a definite > problem. It's no less discoverable than the left button. Right-click menus need to work two ways though: a. Press and hold down right button, move, release b. Click (press and release) right button, move, click either button ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel