define plane

[uwam2ie]

In recent UG version when I was defining a plane from two lines the result was the plane of the two lines. ...Work as ist should. In younger Nx versions after I selected the two lines the preview is a plane vertical on the first curve, and the third alternate solution is a plane the old way. Why is this solution at third place and not the first choice...
this cost in minimum of two clicks. enhancement?
thx in ad

 

[JohnRBaker]

What do I tell the guy who thinks that 'Through Line, Normal to Vector' is "working as it should"?

John R. Baker, P.E.
Product 'Evangelist'
NX Design
Siemens PLM Software Inc.
Cypress, CA

http://www.siemens.com/plm

http://www.plmworld.org/museum/

 

[uwam2ie]

John,
if selected in the dropdown plane from two lines.
... extra dropdown dialog called
maybe line and vector
thx in ad

 

[JohnRBaker]

That of course would require an additional icon and yet the selection workflow would be identical, selection of 2 lines, and for the line/vector method we would still have to add a 'cycle' option to cover the 2 possible cases there. Currently we have ONE icon and a cycle option covering 3 cases.


John R. Baker, P.E.
Product 'Evangelist'
NX Design
Siemens PLM Software Inc.
Cypress, CA

http://www.siemens.com/plm

http://www.plmworld.org/museum/

 

[uwam2ie]

John,
whats easier, the user:
Plane dropdown, 2 Lines
select lines -> goto plane option ( open option ) move mouse to
select alternate solution click three times
->Ok
or
Plane dropdown, 2 Lines
select lines
-> OK
Plane dropdown, line vector
select line , select vector (line)
-> ok
... get there faster ( I-deas ; ) )

thx in ad

 

[ewh]

I think I have to agree with John. While the I-deas method may be quicker, a plane from two lines in not intuitive, but is actually derived from 3 points (two line end pts and the third pt). Two lines on their own DO NOT define a plane.

Believe it if you need it or leave it if you dare. - [small]Robert Hunter[/small]

 

[uwam2ie]

ok,
other question is there a key accelerator to define alternative solutions? or how can I define one maybe on the tab key
thx in ad

 

[hudson888]

Guys,

It seems like there is some healthy and interesting debate on the subject. My take on this would be that two lines don't necessarily define a plane, unless they are already co-planar. However finding two lines on the same plane is quite usual in engineering so it is valid to want to support this method. It is a simple method of construction and people will expect the simplest to be the easiest.

In terms of what to prioritize there are so many methods of defining planes that you could go on finding them I suspect for ever. There are however only a few that are basically intuitive such as a flat face, three points, an arc, or perhaps two lines that lie on a plane already. These should be easy for the user to find because you would expect to be able to do it intuitively. In other words the user's intuition when matched by the way the dialogs are written combine to make the system seem intuitive. The system itself is said to be intuitive, but it isn't really it just matches the user's expectations so closely that the user is lulled into a feeling that the system knows their will.

"Any sufficiently advanced technology is indistinguishable from magic." Arthur C. Clarke.

On the other hand the most useful methods for defining planes are things like tangent to a cylinder, parallel to another planar face, at an offset to something else planar and the along a curve, among too many others I could mention. The thing about all of these is that they fall within the scope of what most users might expect, or have come to expect from previous use, and yet they go beyond the first group because they create a new object based upon others but useful for constructing something beyond what already existed. It is precisely because these objects are so darned useful to build with that many would prioritize these ones over all others.

Of all the types of datum object construction I would like to see supported but least expect to use frequently are some vector based methods that frankly make one think too much and are poorly understood by most users. There may be some things that are particularly clever to be done with these and so on the rare occasions when they're needed they'll be absolutely invaluable.

Without making any judgment on what John and others have said, (I'm not able to test it right away, but will later no doubt), I would expect the most useful methods to take slight priority since they will probably be the most frequently used.

I hope that this puts things in a better context. It seems to me that there can be a philosophy of intuition as applied to creating dialogs that are both useful and "user friendly", and that as users we have a big stake in shaping this since we have to either enjoy or endure what PLMS create for us on a daily basis.

Regards

Hudson

 

[JohnRBaker]

Another saying from some anonomous engineer (at least I assume this came from an engineer) that is very relevant when it comes to designing User Interfaces:

"That you can't make something simpler by adding to it."

In this case, since we can't avoid having a '2-way cycle' option for the 2 non-planar lines case (as that is always ambiguous), it was 'simpler' to have ONE icon with a '3-way cycle' option than TWO icons, one with and one without, a '2-way cycle' option.

John R. Baker, P.E.
Product 'Evangelist'
NX Design
Siemens PLM Software Inc.
Cypress, CA

http://www.siemens.com/plm

http://www.plmworld.org/museum/

 

[hudson888]

Well John,

It becomes a question of what is simpler the user or the system.

Regards

Hudson

 

[uwam2ie]

hudson,
I agree ...
...
has anybody an idea to get a quicker way to acess the alternate solution?
thx in ad

 

[ewh]

I'm still with John on this. I don't want "my" software catering to the lowest denominator, because there is no limit. Some previous knowledge of geometry should be a prerequisite.

Believe it if you need it or leave it if you dare. - [small]Robert Hunter[/small]

 

[hudson888]

Apologies to all who agreed and disagreed with my comment above in error. While I did intend to link the idea of simplicity with intuition in a positive vein. My comments earlier surely did not favor the lowest common denominator.

A user on this forum has a very good tag,
"Everything should be designed as simple as possible, but not simpler."

I am generally in favor of giving priority to the most useful dialogs, based solely on the presumption that they would be the ones needed most frequently.

It also occurs to me that sometimes a slightly more complex dialog presents one with more options meaning that although you probably won't use all the tools every time at least it is helpful to have them presented to you so that you know they exist. Having to find things seems to be a recurring theme in answering peoples queries posted on the forum.

If John says that it requires an extra keystroke to do something then I absolutely believe that to be the case. On the other hand I posted in sympathy for the guy who finds things changing in dialogs for reasons he doesn't understand, because I can't see why he has to like it if it doesn't give him a better experience of using NX.

Perhaps for the future it needs to be considered that different people do use the system for different things and in different ways, and at the same time you don't want to proliferate dialogs for any reason that creates duplication in the system because it would be a waste of resources. The solution may be along the lines that when you enter a dialog it presents in the state that you last used it, so that if there are alternative methods for doing different things under icons or tabs then there may be some benefit in expressing the user's preferences by always presenting him with his preferred context. It's not to say you could do it for this dialog, or that anyone is strictly right or wrong but that I'm hearing this as the need for some flexibility in how the system works.

Hope this clears things up.

Regards

Hudson

 

[JohnRBaker]

OK, for what it's worth, I have to agree that while we did implement this correctly in the sense that it was better to implement a SINGLE Datum Plane creation function that handles both coplanar and non-coplanar situations (besides, I just thought of another issue and that is that if we had a dedicated 'coplanar' only function we would then have to issue errors when users attempted to use this function on non-coplanar lines and vice versa) than 2 different functions, that we probably should change the ORDER of the possible solutions so that IF the 2 lines selected WERE coplanar, then the FIRST solution offered should have been the one where the 2 lines were lying in the plane of the Datum Plane. Currently that option is always the LAST of 3 possible solutions when the lines are coplanar. Note that when they are NOT coplanar there are only 2 possible solutions and since this is a completely ambiguous case, there is no one solution that is likely to be better than the other, however, as has been argued here, there appears to be some sort of consensus that when they are coplanar that there is a 'more better' solution and that one should be FIRST on the list of alternative solutions.

To that end, I've opened a PR using the argument that since there appears to be somewhat of a consensus that when the 2 line ARE coplanar, that the most desirable solution (and I agree with this) was the one where those lines will lie in the plane of the Datum Plane that is created, and that in the less frequent cases where one of the other 2 solutions is desired that only then should the user be expected to use the cycle button.

Now I can't be sure this will even be accepted as a PR or even something that we should spend resources on to 'fix', but I'm giving it my best shot and I'll let you all know if and when I hear anything back on this.


John R. Baker, P.E.
Product 'Evangelist'
NX Design
Siemens PLM Software Inc.
Cypress, CA

http://www.siemens.com/plm

http://www.plmworld.org/museum/

 

[JohnRBaker]

I have good news!!!!.

I was just notified that per my PR (see my previous posting above), development has agreed to my suggestion that if the 2 lines being selected to define a Plane were coplanar, that the FIRST solution offered when cycling the Alternate Solutions will the Plane where BOTH lines are lying in the plane. In other words, what is now always the 3rd of 3 Alternate Solutions, will now be FIRST if the coplanar conditions are met. This change will be made in NX 6.0, which will be released later this year.


John R. Baker, P.E.
Product 'Evangelist'
NX Design
Siemens PLM Software Inc.
Cypress, CA

http://www.siemens.com/plm

http://www.plmworld.org/museum/