[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
frontend redesign :-)
- To: <michael>
- Subject: frontend redesign :-)
- From: Eric Dean Tribble <tribble>
- Date: Wed, 20 Sep 89 15:24:47 PDT
- Cc: <us>, <tribble>
- In-reply-to: <Michael>,30 PDT <8909201156.AA23620@xxxxxxxxxx>
Date: Wed, 20 Sep 89 04:56:30 PDT
From: michael (Michael McClary)
(The description is so graphic that my fingers itch for a mouse...)
My fingers have itched to do this style of interface for several years....
I think I prefer an explicit icon for the group to the Macintosh
idiom "mouse-down sorta on the selected group grabs the group".
That makes your cursor modeful, and I often have trouble figuring out
where a mouse-down will grab the group, and where it will deselect it.
Hmmm... "Click" on a singleton is "select/deselect", while "double click"
is "show/hide children". For a set-of-selections floating button,
"double click" is "copy/move". Is there any reasonable operation that
could be thought of as "open/close" for a set of selections? Is
Sort of. If we choose to represent groups of siblings in which some
of the siblings are collapsed, then the close operation collapses a
set of siblings into a thin dashed line or some such to ge them out of
the way (I really want this feature, but it can certainly wait for rev
2). The dashed line would then become the button to reopen the
"(single) click" defined? (Zero-length drag? Deselecting a group
would make the group button vanish - not nice.)
Aha! Double-click could be "nail it down here". This opens space
AROUND it. Double-clicking again it unnails it. Now you need a
replacement for the copy.
How about double-click beside a floating button for "make a copy of the
button (and thus what it represents) appear. Downsides: Your cursor
becomes modeful again, and a near-miss could do the wrong thing.
Peahaps double-click in never-never-land could mean "Make a copy of the
floating button for the current designated-group here" Single-click
without drag would make it go away, but another double-click would get it
back. (Not nice. You could always get rid of it by throwing it in a
trashcan-equivalent.) This would have the advantage that you wouldn't
have to drag across multiple screens when copying, but the advantage
would be missing for move. Hmm...
It's important not to change the behavior of anything else on the
screen when the button appears. That means that we can't have a
special behavior for clicks near the selection button, nor should we
change the behavior of the mouse over text.
Naw, it's getting baroque. Why a nail-down when you could just leave
it there? (Letting go the button would open the space, dragging it
out and letting go would close it.) Let's skip symmetry, and keep
double-click on a selection-shorthand button meaning duplicate. (That
means you need the floating button even if only one thing is selected.)
We could have a save bar somewhat like the icon doc of the next
machine. If you move a selection icon over a particular spot (the
right border?) it wouldn't go away when the user made some other
selection. The scheme that I prototyped in viewers for saving a
selection let you just drag the selection icon over the desktop
background and leave it there. You could late pick it up and put it
in some other text.