Hi,
Yesterday, I watched a 7-year old girl use Etoys to assemble a face using ellipses and rectangles. Sometimes, the rotation center had to be changed from the default for embed ops (e.g. ears). I had taught her to bring up the halo menu and and use the red menu button to turn on the direction handle. She discovered that moving the rotate button leaves behind the direction handle and preferred to use it. When the rotate button is used, the direction handles appear and stays on even when the rotation ends with the original heading.
My initial reaction was to make a note to file a trac ticket. But then, watching the ease with which she used the rotate button to bring up the direction handle and move it around, I realized this jiggle gesture comes easily and naturally than shift click for children. Jiggle the dup button to get a sibling, jiggle the color button to get a property sheet and so on.
BTW, I made a one-liner fix to use simple drag (instead of shift-drag) for moving direction handles. If others can try this out and find it useful, I will file a ticket for its inclusion in Etoys.
Subbu
At Tue, 22 Jul 2008 14:37:39 +0530, K. K. Subramaniam wrote:
[1 <text/plain; utf-8 (7bit)>] Hi,
Yesterday, I watched a 7-year old girl use Etoys to assemble a face using ellipses and rectangles. Sometimes, the rotation center had to be changed from the default for embed ops (e.g. ears). I had taught her to bring up the halo menu and and use the red menu button to turn on the direction handle. She discovered that moving the rotate button leaves behind the direction handle and preferred to use it. When the rotate button is used, the direction handles appear and stays on even when the rotation ends with the original heading.
My initial reaction was to make a note to file a trac ticket. But then, watching the ease with which she used the rotate button to bring up the direction handle and move it around, I realized this jiggle gesture comes easily and naturally than shift click for children. Jiggle the dup button to get a sibling, jiggle the color button to get a property sheet and so on.
An interesting idea!
BTW, I made a one-liner fix to use simple drag (instead of shift-drag) for moving direction handles. If others can try this out and find it useful, I will file a ticket for its inclusion in Etoys.
Yes, I am still often caught for not pressing the shift-key so it would be useful. But there may be some reasons for it to be in that way that I'm not aware of... Scott?
-- Yoshiki
On Jul 24, 2008, at 1:15 AM, Yoshiki Ohshima wrote:
At Tue, 22 Jul 2008 14:37:39 +0530, K. K. Subramaniam wrote:
...BTW, I made a one-liner fix to use simple drag (instead of shift- drag) for moving direction handles. If others can try this out and find it useful, I will file a ticket for its inclusion in Etoys.
Yes, I am still often caught for not pressing the shift-key so it would be useful. But there may be some reasons for it to be in that way that I'm not aware of... Scott?
The decision to require the shift-key was in response to a real and constant classroom issue at the time, arising out of two critical differences in halo policy in force back then:
(a) "Mouse-over-halos" were used. So just moving the mouse pointer over a Sketch automatically brought up a halo around the Sketch.
(b) Halos on Sketches always included the center-of-rotation handle -- no need to operate the blue rotation handle first (the showDirectionForSketches preference was set to true.)
Therefore, when a child wanted to drag a Sketch, just moving the mouse pointer over it brought up a halo, and that halo always included the "center of rotation" handle, typically right at the center of Sketch, right where the child was likely to grab it if intending to "pick it up."
So it happened, very often and very annoyingly, that the child ended up dragging the center of rotation when she had no intention of doing so. And the result was often very mystifying.
Thus the guard.
Nowadays, however, we operate with mouse-over-halos turned off, and with the showDirectionForSketches preference turned off as well.
Thus, inadvertent operation of the center-of-rotation handle in a modern etoys system would be very unlikely.
So I would support removing the shift-key requirement.
-- Scott
On Friday 01 Aug 2008 4:23:49 am Scott Wallace wrote:
Therefore, when a child wanted to drag a Sketch, just moving the mouse pointer over it brought up a halo, and that halo always included the "center of rotation" handle, typically right at the center of Sketch, right where the child was likely to grab it if intending to "pick it up."
mouse over halos are useful when the pointer has a single button only (e.g. handhelds with touch stylus.
Pick-on-click changes the z-order and I have seen children getting flustered when many minutes of careful stacking gets changed by a casual click. Treating click-drag as a move may be a better option.
How about the following for handling mouse events?
if mouse-over-halos is true then on hover bring up halo. bring up direction handles based on pref if bluebutton is pressed bring up halo with direction handles always. and then if halo is on ignore mouse clicks outside of halo buttons and dir handles. allow dir handle to be moved/rotated using direct drag. else allow morph to be moved using direct drag.
Nowadays, however, we operate with mouse-over-halos turned off, and with the showDirectionForSketches preference turned off as well.
If direction handles are always shown, kids learn to anticipate its appearance. I introduce it to them as "legs" (arrow is the big toe) around which the morph can turn or leave a trail. This metaphor goes well with the overall theme of costumes and players.
Subbu
At Fri, 1 Aug 2008 13:35:02 +0530, K. K. Subramaniam wrote:
How about the following for handling mouse events?
if mouse-over-halos is true then on hover bring up halo. bring up direction handles based on pref if bluebutton is pressed bring up halo with direction handles always. and then if halo is on ignore mouse clicks outside of halo buttons and dir handles. allow dir handle to be moved/rotated using direct drag. else allow morph to be moved using direct drag.
If I understand correctly, this doesn't handle the case when the morph is a button or such. A button should behave as a button even if the halo is on. It is especially true when mouse-over-halo is on. Let us say the button is near the corner (which is often the case), and the user trys to click on it to activate the button action. In the split second, the halo might show up and the user would click on a handle. That would be bad.
And, in general, the above has way too many cases to my taste.
Nowadays, however, we operate with mouse-over-halos turned off, and with the showDirectionForSketches preference turned off as well.
If direction handles are always shown, kids learn to anticipate its appearance. I introduce it to them as "legs" (arrow is the big toe) around which the morph can turn or leave a trail. This metaphor goes well with the overall theme of costumes and players.
Not doing mouse over halo and showing the direction handle always, and not requiring shift-drag would be pretty good.
-- Yoshiki
etoys-dev@lists.squeakfoundation.org
-
K. K. Subramaniam -
Scott Wallace -
Yoshiki Ohshima