In its simplest form this is what makes the most sense
Source -> Target
The constrained object->That which constrains
Child->Parent
>From a human perspective the concept of source-target is clearly unambiguous.
Arrow->target
Baseball->catchers mitt
Basketball->hoop
Bucket of water->fire
Hammer->nail
Machine gun->warplane
Train->Rail
Brick->building
Hanger->closet rod
Spacecraft->Moon
We first grab(select) or handle something and then we articulate it toward,
into, or on the target.
This is not a concept of hierarchy. This is a concept of directional procedure
for selection order. This is about a concept of human action extrapolating to
human machine interaction. Verb is most appropriate.
People confuse the concept of hierarchy with selection. A parent is a form of
constrain. Both a constraining object, a parent, a rail have a level of
hierarchy and ownership over its children or constrained objects. Within
hierarchy the parent precedes the child. But in action of constructing the
hierarchy we, as humans, we most often articulate the subordinate toward the
parent. We must first gather the children in order to construct the target. The
bricks are the source and target is the building. In construction procedure the
building does not precede the bricks. We find bricks, then articulate them
until a building, the target thus takes shape. Target is secondary in action.
Even technical people understand this. Especially technical people. You have to
create the spaceship before you can go to the moon. You don't bring the moon to
the spaceship. That is illogical. If you could do that the target would be the
spaceship and there would be no point in the endeavor because the moon would
already be in your possession. As a goal the Moon is primary. As an action the
Moon is secondary. You have to make and articulate the spaceship first in order
to reach your goal. Developers frequently conflate goal with target. They are
not the same.
Are there examples where target might precede the source. A few. One could say
that the bucket precedes the water but that would ignore the context by
ignoring the shift in targets through procedure. For example:
Bucket->water
Bucket of water->fire
One can't easily pick up molecules of water one at a time and place in the
bucket the way you can efficiently pick up apples and place in the bucket. Then
you would select what might be considered the target first (the bucket) and use
this "target" to collect the source, but it is defined as source by the intent
of the water's purpose. The bucket is in fact the source and water the target,
before the water becomes the source and the fire the target.
Setting target before source is then the exception, not the rule.
In terms of procedure the item doing the looking is source, the looked at item
is target. Anyone who has ever picked up a firearm, bow and arrow, ball and
bat, or operated a battleship machine gun tracking an aircraft will tell you
that. This is how we as humans think. Extrapolating to that is intuitive.
Extrapolating in the inverse, while occasionally practical, is less frequently
intuitive in terms of procedure.
--
Joey Ponthieux
__________________________________________________
Opinions stated here-in are strictly those of the author and do not
represent the opinions of NASA or any other party.
> -----Original Message-----
> From: [email protected] [mailto:softimage-
> [email protected]] On Behalf Of Luc-Eric Rousseau
> Sent: Friday, February 20, 2015 12:20 PM
> To: [email protected]
> Subject: Re: Maya thinks they're clever....and that's the problem
>
> Hello I know what you're saying, but the way I saw it, those scenarios were
> "select the many, and then highlight the one". This allows you to select
> everything and then highlight the "target" for example the motion path or
> the parent, and the UI supports that paradigm with the green highlight of
> The One.
>
> Thinking in terms of source and target is not always unambiguous in UI. For
> example, if you have a menu that applies a LookAt constraint, what's the
> "target", is it what the object will end up look at, or what the object the
> menu command acts upon. A technical individual might see things as picking
> all the inputs of an operator and then the output, and an artistic person
> might see things differently and read it like subject/verb/object.
>
> On Fri, Feb 20, 2015 at 1:11 AM, Ponthieux, Joseph G.
> (LARC-E1A)[LITES] <[email protected]> wrote:
> > I think you've missed my point. Some of Maya's selection context is done in
> a normal or intuitive manner. Others are not. The point is that Maya's
> selection contexts are all over the place and the fact that some processes
> bear out multiple contexts only confuses matters. In the case of parenting,
> Maya gets the natural selection order right with the target being last. Its
> the
> majority of other processes that are unintuitive and inconsistent with this
> one.
> >
> > I fail to understand how having to read the status line everytime i parent,
> constrain, or path animate something might be intuitive.
> >
> > I've been using using Maya since 98. I know where to get the status line
> information. I've written MEL scripts that post status line instructions.
> Thats
> not the point.
> >
> > The point is that the selection methodology in Maya is inconsistent,
> incongruent, and unintuitive. As if though each process was written by a
> different person at a different time and nobody knew what the other person
> was doing. This incongruency demonstrates that Maya completely ignores
> how and why we as users, as humans, think when it comes directionality of
> source -> target and how percieve this concept.
> >
> > This should be a simple intuitive process that the user can instantly
> extrapolate without having to read the manual every time you switch from
> parenting to constraints or animating. This is selection methodology. We do
> this one task, select items, hundreds of times a day. And Maya has no
> uniform selection paradigm. In fact Attach to Motion Path can even mislead
> the user into adopting bad behavior by allowing the user to think the
> selection order is one way until you go to motion path one curve on another
> and then it can be opposite the way someone has earned to attach objects
> to a curve. This is illogical.
> >
> > The original poster has a valid and salient point. And its not enough that
> > all
> contexts are the same. They could all be the same and still be unintuitive
> because they could be contradictory to the way we think about selection
> naturally. Selection has to be designed to the way we as humans think and
> not just a procedure for the sake of being a procedure.
> >
> > From: Luc-Eric Rousseau [[email protected]]
> >
> > On Thu, Feb 19, 2015 at 2:23 PM, Ponthieux, Joseph G.
> > (LARC-E1A)[LITES] <[email protected]> wrote:
> >> (as already noted by another poster)
> >>
> >> If you have two primitives selected, and attempt to parent constrain,
> >> the second selected object will constrain to the first
> >>
> >> (as already noted by another poster)
> >>
> >> If you have two primitives selected, and attempt to parent, the first
> >> selected object will become child of the second
> >
> > isn't this because you'd select all the children you want to parent,
> > and then finish with the single parent, or select all the object you
> > want to parent-constraint to, and then finish the single target?
> > The "single" object is always last and highlighted in green vs other
> > ones in white.
> >
> >
> > btw, it's written on the help line at the bottom of the screen what
> > you need to select to run the menu command:
> > Parent: "Parent the selected object(s) to the last selected object"
> > Contraint->Parent: "Select one or more target followed by the object
> > to constrain"
> >
