[Bf-funboard] workflow / reworking of ctrl-t, ctrl-p, ctrl-c, etc

The Fallen Weeble bf-funboard@blender.org
Sat, 27 Sep 2003 10:20:14 -0400


Not to butt into the discussion, but I think that while your intents are
honorable you might be barking up the wrong tree.  IMO, the "active"/"selected" thing needs to be clarified a bit.

1. "Active non-selected" probably shouldn't exist as a state at all.

2. There should be a strong visual representation of that.  The Red and
Blue idea you suggested is a bit drastic, but it's the right idea.  We
can probably do something with the existing colors for selected objects,
but make the Active object even more distinguished (like white, since we
all ready use that for objects we are acting upon - like when
translating, rotating, or scaling).

As far as your list of objects popping up when doing a Track or Parent
action, I think the intention is good, but it will probably confuse more
new users than clarify things for them.  Currently, it's pretty
straight-forward: select the stuff you want to work on, select the
active object, issue the command, confirm.  With your suggestion, it
actually adds ambiguity to the situation.  A user (new or otherwise)
would initially view your pop-up list and say "Whoa!  What's all this
stuff?"  You're giving a bunch of extra options and information that you
don't need to.  The fact, also, that many users (especially new ones)
don't give their objects meaningful names also confuses the issue,
with or without visual feedback like the highlighting you suggest.

I think clarifying what is active and selected as well as making the
confirmation dialog a bit more clear (but keeping it simple!) would
effectively make this a non-issue.

Then again, that's just what I think.

  Groo

On Sat, Sep 27, 2003 at 10:15:25PM +1000, Luke Wenke wrote:
> Hi Matt,
> > I think some of these discussions may be getting on to the wrong track a
> > bit, as some of the suggestions seem a bit un-blenderish to me.
> -----------------
> I am exploring methods that are easier for beginners to understand while at
> the same time are good for power-users. BTW, I've addressed many of the
> problems you mention before... so I may sound like I'm repeating myself.
> 
> > The Blender workflow seems intuitive and visual, and I fear that choosing
> object names
> > from lists etc. is quite opposite to that Blender 'feeling'. When I'm
> > working I generally don't tend to name my objects (lazy perhaps?), but
> work
> > in the viewport. I remember something by the way it looks and it's
> position,
> > not by a name.
> -----------------
> As I said, when you are hovering your mouse over the names of the items, the
> corresponding 3d object would be highlighted (perhaps in all available
> views). You can move through the list quickly to see the objects highlight
> and show themselves...
> Or you can choose the active item like you normally do.
> 
> This is how ctrl-T currently works:
> 1) select some things
> 2) make sure the right thing is active
> 3) ctrl-T
> 4) left-click without moving the mouse (or click elsewhere or esc to cancel)
> 
> And you can do exactly the same thing using my method!
> Except that instead of the menu saying:
> =========
> *OK?* (bold)
> Make Track
> =========
> 
> It would now say:
> =========
> *Track...* (bold)
> active-item1
> -----------
> other-selected-item1
> other-selected-item2
> =========
> 
> And instead of the mouse beginning over the word "Make Track", it will
> appear over "active-item1" (or whatever the active item is called).
> 
> And you can still cancel in exactly the same way to the old method. (esc or
> move or click outside the menu)
> 
> -----------------
> > Although Luke's method may seem just as fast (same number of mouse
> clicks),
> > it wouldn't be in practise, as the more inconsistency means that the user
> > must spend more time remembering for a split second "oh I have to choose
> the
> > selection *afterwards* for this command" rather than just doing it
> > naturally, the same was as everything else.
> -----------------
> If implemented, it should be done consistently involving all the relevant
> functions of blender.
> 
> BTW, I see g/r/s as being quite different - they only involve the selected
> items, and if the active item isn't selected (it is possible to select other
> things while the active thing is unselected) then the active item is
> ignored. On the other hand, ctrl-t, etc, always use the active item, whether
> it is selected or not.
> The g/r/s functions only involve one group of objects.... ctrl-t, ctrl-p,
> etc, use two groups of objects (the active item and the non-active selected
> items). Also, there is no pop-up menu to confirm g/r/s like ctrl-t, etc...
> so they are quite different in blender.
> 
> > Although it's not as consistent as it probably should be, to me, it seems
> > that most Blender tools work in a way like:
> >
> > 1. Select something to operate on
> > 2. Invoke command (via hotkey/toolbox/menu/whatever)
> > 3. Optionally visualise or predict what will happen either interactively
> > (like move/rotate/scale) or non-interactively with a confirmation dialog
> > with an opportunity to cancel/undo the command
> > 4. Confirm or cancel the command
> ======================
> My idea has those steps, except that the active item can be changed in steps
> 3 and 4 (by moving the mouse before you click or press enter). And as said
> earlier you can still just select the active item in step 1 or cancel the
> operation after you've press ctrl-T (using esc, etc).
> 
> > I think this sort of workflow is why Blender is quite usable without an
> > 'undo' function. Rather than letting the user do things, mess up and undo
> > it, Blender often gives a way out before enacting the command in the first
> > place. It's like that Raskin UI theory of always giving people an exit or
> a
> > way to undo - Blender often does it, but more integrated with the workflow
> > rather than as a separate command.
> -----------------
> As said earlier, that is part of my idea.
> 
> > To be consistent with this, I like beatabix's suggestion:
> > 1. Select the objects as usual, with one active
> > 2. Invoke track command (via hotkey/toolbox/menu/whatever)
> > 3. Display a confirmation along the lines of "Track selected to <active
> > object's name>" and at the same time, draw the helplines (perhaps
> partially
> > transparent?) from the selected objects to the active object so you can
> visu
> > alise what will happen when you confirm the command.
> > 4. Confirm or cancel the command.
> -----------------
> My idea is virtually identical to that except step 3 isn't ambiguous. You
> aren't actually Tracking the selected items to <active item>.... you are
> only tracking the selected non-active items to the active item.
> 
> My popup menu would look like this (with the mouse beginning on the the
> active object's name):
> *Track....* (bold - since it is a key word)
> <active item> <-(mouse pointer starts here)
> ------------
> <other selected item 1>
> <other selected item 2>
> <other selected item 3>
> 
> While their mouse is hovering over active item's name, the "helplines" you
> describe in (3) could be drawn.
> 
> Then you left click on <active item> (it's name in the menu, where the mouse
> already is) to confirm. (or press esc - or select something else, while at
> the same time the objects change to reflect which one is the new active
> object)
> _______________________________________________
> Bf-funboard mailing list
> Bf-funboard@blender.org
> http://www.blender.org/mailman/listinfo/bf-funboard