why same look and feel?

I found the interesting similarity while working on different CAD
packages.

Each package has a command window,screen menu (ideas,proe and
autocad)etc.
One may find it obvious But why I am posting the related question is
today there is a "windows gui used as an standard" for CAD package
interface but when the CAD industry was in its infancy stage , how
came all the above packages used the almost-same terminology and
look-n-feel interface?
was also there a standard then for such things?
(I omit solidworks from this because it has been developed
recently.Does anyone know a dos or unix version of solidworks?)
somehow I feel PTC used the autocad interface(screen-menu) for their
Proe package as IDeas was graphical-menu based right from the start?

awaiting for your opinions on this...

regards,
Yogesh Joshi

 

You have a lot of questions on how CADs are build, Yogesh... Want to make a
new one ?

CADs are similar for the same reason that a car is similar to another car :
innovation is (usually) an incremental process in which competitors improve
an existing product by taking good ideas from the competition or from the
same research work...
Besides, learning time is an important factor in user cost, so any user
interface (UI) should be as intuitive as possible to reduce it where
"intuitive" generally means "as close as possible to other software's UI..

Remember that a "standard" UI might be significantly different from an
"optimal" UI . The best story I have is the QWERTY keyboard, which was
designed to SLOW DOWN the pace you could type on mechanical typewriters, to
prevent the hammers to collide while typing. There would be much more
efficient keyboard layouts today, but training time makes them commercialy
unviable
(http://www.stanford.edu/group/mmdd/SiliconValley/David/QWERTY.html)

So if you intend to write a new CAD, you should probably stick as much as
possible to the UI of existing ones.

 

I think I-DEAS users who have tried their hand at UG NX would argue
with the "almost-same terminology and look-n-feel interface".

 

Really? Why's that? Is I-DEAS end-of-lifed yet?

Oh by the way isn't SolidWorks older than SolidEdge? Anybody talk about
IronCAD anymore... that's kindof newer than either. -meld

 

2+2=4

y=mx+b

If someone visited us from another planet our initial communication
would be in some form of graphical mathematics.

It all probably has to end up looking very familiar - because IT IS.

 

No, but it's coming. "Do you hear that sound, Mr. Anderson? It is the
sound of inevitabtility".

The last release of I-DEAS, I-DEAS NX 12, will be released in the
latter half of 2005. After that, I-DEAS users are expected to migrate
to UG NX 3 (or later) before 2008, when I-DEAS support is scheduled to
end.

I-DEAS and UG will be basically interoperable as far as data goes by
I-DEAS 12. Interface and functionality-wise, the I-DEAS philosophy is
basically being scrapped in favor of the UG model. At least that's
what the users are seeing so far.

 

The reason behind constantly asking you about CAD,parametric design
and other related questions is...
The person under whom I am completing my project is very much against
using drafting packages as he thinks now a days all the *CA-Design*
package produce drafting as a biproduct so there is no need to learn
the drafting packages as such.
and I also followed his views till some days back.But it's very hard
to understand the parametric and feature desing concepts without not
knowing the principles of *CADrafting* as in *CADesign* literature
also the limitations of drafting package are referred while
explaining the above terms..So I was under lot of confusion whenever
he was refering to the terms like constraint based and other terms.So
I started learning autocad by my own and now I have almost a mature
view of the terms used in Design and Drafting.It is a sort of
revealation to me now as I studied the CAdesign packages first , then
learned drafting packages and now studying both with historical
perspective in mind.

while working on solidworks,catia,UG,Ideas and Proe I observed
following things.
all the packages except I-DEAS used the sketcher and datum plane
concept.?
and also IDEAS seems to be more easy than any other packages.?
eg. How to draw a through or blind hole starting from one vertex of a
cube and diagonally cutting the cube or how to draw a hole on the
cylindrical surface of a cylinder.?
In Ideas you can rotate or move the reference planes but I have not
seen this facility in SW or CATIA?
How to do the above things in other packages?

regards,
Yogesh Joshi

 

(yogesh) wrote in message
(snip)

I-deas started out as a menu based system. This was pre Master Series
code. SDRC spent a lot of money and time developing their current
interface. It, even today, is a damn good, well thought out
interface.

 

y=mx+b?

 

y=mx+b?

One of the ways to express a straight line.

After you've established the context "Hey, look, they're showing us pi,"
decided on a base... Then you need to start constructing sentences to
learn/teach grammar.

 

In England we are taught it as: y=mx+c

Seems like we immediately have a deviation from 'same look and feel'.

 

(yogesh) wrote in message
(snip)

Your mentor is correct in the vision, however the reality today falls
quite short of the mark.

The key problem area lies in communicating the design intent outside
the modeling system. Very few MCAD systems today support the elements
needed to properly represent design intent outside of the 2D drawing
context. Notably, I-deas has this in the form of PMI data that exists
as fully 3D model annotations that can include most common design
intent representations directly on the model. (ie: tolerance, GD&T,
Manufacturing notes & such..)

Those systems with this capability still only address half of the
problem. Viewing this data outside the system is problematic in that
either a license of the system is needed to directly use the data, or
the data must be exported to either a neutral format (VRML, for
example), or a semi-neutral format for use with view/markup software
of some sort.

Other issues involve access to the data in many different settings.
3D representations can be viewed and printed, but still require heavy
resources to actually move about as easily as 2D representations do.
This can sharply limit what data people have access to, particularly
when they are working off-site away from the master data repository.

Having said that, many 2D techniques such as layouts can continue to
be useful in the 3D context when used as the basis for associative
models.

These basic problems, combined with the lack of appropriate features
and problematic translation of even basic features between systems are
the primary drivers behind ongoing 2D work today.

For some problems, creative feature based tolerancing can go a long
way toward addressing the communications issues, however geometry
translation can still be an issue in many cases.

I agree with the core idea that drafting packages should see less use,
but we have another basic problem to solve (assuming the above can be
reasonably addressed. That problem is compute power. The CPU's of
today cannot easily manupulate full parametric, feature-based model
representations easily. The bottlenecks of both computer power and
RAM to hold the result limit what can be done on a PC, while more
expensive UNIX systems can hold the datasets, their CPU power is
lacking and they are expensive.

The mostly sequential design of most MCAD packages today also prevent
multi-threading, and or clustering from addressing the compute side of
things, at least where MCAD is concerned. (Analysis tends to benefit
greatly from at least the clustering technologies today.)

On the PC, the win32 OS places a constraint on RAM as well. Linux
holds some promise in this area, but few systems have ports at this
time able to really take advantage of the additional addressing
capability. (Also PC hardware vendors largely target the win32 OS,
for good reason, making this even more of a niche approach for MCAD at
this time.

Personally, I am not sure the parametric systems will ever get there.
Variational systems exhibit strong potential in this area, but they
are not the majority at this time. (I-deas being the most variational
one out there, but with strong parametric leanings at this time.)

Both of these will eventually get addressed one way or another, but
until that time we will continue to be limited on model size. Most
systems today employ clever (and some not so clever) schemes to enable
the user to easily address parts of the model as needed for authoring
or changes.

While these limits are in place, 2D methods may continue to provide
enough benefit to justify their ongoing use for some time yet.

(snip)

I-deas does use the sketcher concept, though it does have both 2D and
3D representations, making things difficult to nail down. A datum
plane is pretty much equal to an I-deas reference plane and or
coordinate system.

An I-deas sketch plane can be a reference plane, solid model face, or
just a set of points in space the user can directly manupulate in a
non-parametric way.

(snip)

No disagreement here

The difference lies in the constraint model used. Strictly parametric
systems basically require that everything be associated, or built off
of, a few primary data points, such as a base coordinate system, or
set of planes.

If you want to rotate a reference plane (datum) in these systems, you
must build that capability into the model in advance. (Violates
Doug's rule of CAD.) Another option would be to redefine the
references used to construct the plane at a later time. (Pro/e, for
example.)

Both options demand, from the user, either advance knowledge of the
model and its potential changes, or in depth knowledge of both the
system and the particular model representation of the model at hand,
in order for the user to make the appropriate changes.

I-deas will allow both the parametric model, or a hybrid approach to
be used. This is hard to explain, without writing a short book...

It works like this:

Anything you build associative to something else that is a part of the
model definition, and is itself associative to the primary coordinate
systems will act as parametric things do. The system will make the
appropriate changes when requested. The definition itself captures
design intent along the way.

Anything you define in a non-associative way, such as via cursor pick,
or via the transform commands, will be associative in every way except
for the actual transform data. (You can think of this as keyed in
data generally not allowed in strictly parametric systems. Generally,
these methods fail to capture design intent in the expected way.

So, if you were to build a loft, for example, using the strictly
parametric model, you would have to first define a bunch of planes to
sketch on, then the sketches, then the loft. Each part of the loft
could be changed according to the flexibility for change built into
the loft.

You could also just build a bunch of sketches in space, or import them
--it makes no difference, then build the loft. When changes are made,
you would be in charge of the spatial location of the loft sketches,
while I-deas would take care of the rest. Assuming the sketches were
built in an associative way, that is...

If they were imported, for example, the entire loft would require
manual modification not too different from the older non-parametric
systems, yet parametric features could be built onto that same loft
that would respond as expected to reasonable manual changes.

So, I-deas is a hybrid modeler in that it can be used in a highly
parametric way, but that requirement is not enforced on the user.
While this does make some things easier (like assembly, and use of
outside model data as the basis for in-system parametric models), it
can cause a lot of problems for the user, unless the underlying
concepts are well understood.

 

Hats off to you doug for such an elaborative reply.!!!!

regds,
Yogesh Joshi

 

I believe there are two reasons why CAD systems are starting to look
more alike:

1.) "Convergence". In naturalist terms, this means that similar
problems will evolve similar solutions. All CAD programs are
addressing the same basic problem, so it is natural for them to evolve
similar solutions.

2.) Calculated marketing. It is easier to convince a customer to
switch to your product if the customer can immediately see
similarities.

Consider also the FEA scene. Many different FEA packages use common
interfaces such as FEMAP and PATRAN. This allows for common
interfaces even though the underlying analysis code is drastically
different.

 

You are welcome. I had a bit of free time and some interest in the
subject. Personally, I wish the MCAD industry today would give these
basic issues greater consideration beyond the simple product
differentiation we see today...

We might actually get more done.

 

Hah!! Yeah, maybe?

Anyhow, Doug, well written!

Yogesh owes you big time!! ;^)

...

 

Seems like we immediately have a deviation from 'same look and feel'.

One arbitrary squiggle on a page is as good as the next.

 

Well, that is the beauty of USENET. Despite the noise, what comes
around goes around. I have gotten a few pretty nice replies in my
time when I needed them, so... there you go!

 

Agreed. IMHO, this is a *major* problem today. Ease of use is being
equated to better or more powerful when really it means less and less
differentiation between competing products mostly using the same
technologies. (I-deas and CATIA being a notable exception here.) I
guess if we could say we have solved the core MCAD problems in the
same way we have word processing problems, for example, this might be
a good thing. I am just not sure we have traveled far enough down
that road yet.

It is interesting to note the direction Alias took with their
products. They adopted the good parts of the win32 environment while
continuing to retain the elements of their GUI that were well thought
out and powerful. Alias remains difficult to learn, yet is very easy
to use once the learning has happened.

Alas, it is also more difficult to articulate a unique value
proposition. These two things combine to reduce much of the
discussion to price. While that is a good thing for us buying
software, in the end we all lose out on potential niche technologies
and options that may hold the potential for competitive advantage over
our peers.

Take a look at the I-deas analysis environment sometime. It is
different in the way Alias is described above. Has the same
advantages as well.

Putting a nice interface on a complex task does not assure the user of
anything other than a nice interface really. Complex stuff is still
complex.

Your point on the solver interface is an interesting one though...

 

IGDS (McAuto) yeah, I don't think UG qualifies, though.

<snip>