On Mon, Jul 09, 2001 at 05:15:13PM -0400, Noel J. Bergman wrote:
> Direct manipulation is a good thing, but UIs can be developed that don't
> require three mouse buttons, a prehensile tail, and a quick reference guide
> glued to the mouse.

That's true.

> Ok, that's certainly tongue-in-cheek hyperbole, but there are already SELECT
> (red), WINDOW (blue), and CONTEXT (yellow) mouse buttons, plus Morphic
> halos.

I'm not adding anything fundamental to this list.  I'm just reworking the halos
a bit.

> > perhaps shift-drag will make the resize be
> > either horizontal or vertical
> 
> This adds yet another thing for keyboard users to remember, not to mention
> making Morphic even more difficult to use on stylus-centric devices.

No, because it's an optional niceity for devices that can support it.
Otherwise, you can just drag carefully to get the same result.  It's
no different from how shift-resize currently results in square bounds;
many people probably don't even know that this feature exists, and do
fine without it.

> 
> > I'm hoping to essentially have 2 "rings" of halos: the
> > inside ring for resizing/rotation, and the outside ring
> > for the rest of the halo functionality.
> 
> I don't believe that meets your other criteria to "clearly [express] their
> purpose without taking up too much room."  From your description it takes up
> even more screen real estate than the current halo package.

Right now, there is no differentiation between halo handles that perform 
direct manipulation actions (resize, rotate, pick up, move around) and those
that do other things (control/debug menus).  The scheme I'm working out clearly
separates "direct" and "indirect" handles; although it takes up more room, it
groups handles by their functionality.

It has other benefits as well.  My motivation for doing this is my
pending integration of Morphic and Cassowary.  Picture a morph whose
bottom is constrained to be at y=350.  Right now, you can drag the
resize handle down, and the extra size will be added to the top of the
morph. Not very intuitive.  Under my proposed scheme, where resizing
can be done from any corner, trying to drag down from a bottom corner
would result in no change (since the bottom edge is constrained),
whereas a resize upwards from a top corner would result in the morph
growing.  IMHO, this is pretty decent behavior.

All in all, a small bit of extra real-estate is worth the gains in both
consistency and functionality that I hope to achieve.  I hope you'll agree
when I release it for comment.

Thanks for your input,
Joshua

> 
> 	--- Noel
> 
>