Non-intuitive target for halo button

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Non-intuitive target for halo button

K. K. Subramaniam
Hi,

When I press red button on a collection of Morphs, the top-most morph is
targetted, but when I press blue button, the halo appears on the outermost
morph. This runs counter to how we 'pick' stuff in real world and I find it
very annoying. Shift-blue gives the right behavior but I wonder how many
people know it.

I wonder which use cases drove the decision to switch the order?

Curious .. Subbu

Reply | Threaded
Open this post in threaded view
|

Re: Non-intuitive target for halo button

Bert Freudenberg

On May 26, 2007, at 15:09 , subbukk wrote:

> Hi,
>
> When I press red button on a collection of Morphs, the top-most  
> morph is
> targetted, but when I press blue button, the halo appears on the  
> outermost
> morph. This runs counter to how we 'pick' stuff in real world and I  
> find it
> very annoying. Shift-blue gives the right behavior but I wonder how  
> many
> people know it.
>
> I wonder which use cases drove the decision to switch the order?

I'd be very surprised if I halo-click a button and it would select  
the embedded label instead of the button to be able to move it. In  
most cases I am not interested in picking up the components of a  
morph, but the morph itself. "Embedding" is considered an advanced  
operation in Etoys, so the default is to narrow down the selection  
with repeated clicks rather than the opposite.

- Bert -



Reply | Threaded
Open this post in threaded view
|

Re: Non-intuitive target for halo button

K. K. Subramaniam
On Saturday 26 May 2007 7:28 pm, Bert Freudenberg wrote:

> On May 26, 2007, at 15:09 , subbukk wrote:
> > Hi,
> >
> > When I press red button on a collection of Morphs, the top-most
> > morph is
> > targetted, but when I press blue button, the halo appears on the
> > outermost
> > morph. This runs counter to how we 'pick' stuff in real world and I
> > find it
> > very annoying. Shift-blue gives the right behavior but I wonder how
> > many
> > people know it.
> >
> > I wonder which use cases drove the decision to switch the order?
>
> I'd be very surprised if I halo-click a button and it would select
> the embedded label instead of the button to be able to move it. In
> most cases I am not interested in picking up the components of a
> morph, but the morph itself. "Embedding" is considered an advanced
> operation in Etoys, so the default is to narrow down the selection
> with repeated clicks rather than the opposite.
By collections I meant morphs in a book/playfield/holder etc. Here is an
example:
I drag a curve morph onto a book. I can use redbutton to pull it out and it
works as expected. But bluebutton halos the whole book. Since most books have
lots of blank area to pick, this behavior is counter-intuitive. The morph
which responds to red should also be the morph which responds to blue. Morphs
placed in playfield work as expected. This is in 3.10 and also on 3.9.

BTW, I overheard my kids distinguish embed and drop ops thus:

 'embed' is like pasting pictures onto a sheet. It sticks and becomes one with
the sheet. 'drop' is like placing blocks on a tray. When you move the tray,
the blocks also move with it, but they are not one.

How's that for 'advanced' :-).

Regards .. Subbu