Thursday, August 11, 2011

Common, But Strange, Product Design Terms

Lately I have been pondering over some of the common product design terms we use in our industry. If you really think about some of these terms, you may find like me that in reality they actually make no sense at all. Perhaps they can tell us much about how software vendors have changed our world.

Here are just a few that I think about. There are many others, but I'm going to pick on these three for now.

Top-Down Design

When humans first designed ships that crossed the oceans, do you think they used top-down design or bottom-up design? I really want to know. How did they do it?

I understand what top-down design actually refers to, but does the contrary, bottom-up, ever yield good design? is there really another choice? Is this term simply used due to the nature of our CAD tools we use today? Are we forced to use this term due to some awkward deficiency in our CAD tool? Try to forget about your favorite CAD tool for just a moment. How would you REALLY approach the design?

In-Context Design

What is the contrary to in-context design? Out-of-context design? What is that? Is real product design ever done out of context? No, never has, never will. So why do we need this term? When the rocket scientists designed the rockets that sent men to the moon, did they design them in context or out of context?

Do you suppose they went to the rocket parts bin, and started bolting parts together to make the rocket? I guess that would be an example of out-of-context design (and bottom-up design), and I bet it wouldn’t work. Do we really need special tools and training to keep our designers from designing out-of-context? Again, why does this term exist? Ignore your CAD tool again for a moment. How would you REALLY design a product; in context or out of context? Is there another choice I missed somewhere along my education or career. Does the use of the term have something to do with our CAD tools?

Design Intent

Is there a difference between "design" and "design intent"? I once heard this response from someone after seeing a demonstration of direct modeling: “No, we could never use direct modeling with our products. Our products demand firm design intent”. (Or something close to that). Wow, many thoughts crossed my mind. Thoughts I couldn't repeat in front of them, but will share here: “Are you telling me that your products are so sophisticated that they couldn't be designed without history-based modeling?” Or worse yet: “Are you saying that you can’t design without history-based modeling?” Another crazy thought: “So you think that this rigid design intent will keep you from making mistakes? Oh, right.” Hopefully they are just telling me that it would be more difficult to design their product without it. I’ll think positive and assume the latter.

It’s almost as if humans were never before able to design, and convey the intent of the design, until we had CAD with history trees. History trees certainly provide a useful method of documenting your design "intent". Do they provide the best method of conveying your design "intent"? (And do we really need to use the word "intent" after the word "design"?)

How do you suppose the caveman above was ever able to document and convey the intent that the center hole had to be concentric, at a specific tolerance, to the outer diameter of his new round wheel? Eventually it had to be done. How’d he do it? By the way, how do you REALLY define design intent? What defines it? If your answer has anything to do with CAD - you are wrong. There are certainly many ways to “document” and "convey" your design intent - with history trees, with 3D models, with 2D CAD, even with paper and pencil. What do you suppose is the easiest and most universally understood method of documenting and conveying your design - intent?

Bottom line: Do our tools fit the process of design, or are we forced to adjust the process to fit the tool?

Paul

13 comments:

Blake Courter said...

Nice post, Paul.

In the old days, history-based CAD vendors would promote "in-context" as the ability to make changes to parts from other deliverables, such as assemblies and drawings. It was another way of demonstrating associativity. Sadly, however, these changes amounted to little more than editing a few dimensions that were designed to convey the illusion of "design intent." It was impossible to make substantive changes. That's one of the reasons we don't have part and assembly modes in SpaceClaim, and why you can rotate and use all the modeling tools in our drawings, including arbitrary cross sections. For us, "in context" means that you can make any change wherever you see it without having to go back to some other window -- including driving it with a reference dimension value on some odd-angled cross sectioned curves on a drawing.

Out-of-context is what happens where you see a problem in some cross section in a drawing and have to go back to the part, try to figure out how to edit it there, then go back to the cross section and see if the problem still exists, and iterate.

As for design intent (or at least well-architected modeling intent), I think there's a place for it once concepts are well-considered and the engineering intent is well understood. Of course, to sort that out, you should start in a direct solid modeler, mesh modeler, or surface modeler that doesn't have constraints and the downstream consequences of feature-based CAD.

I have also met many excellent feature-based CAD users who find the idea of constraint and feature-free modeling terrifying. This concern is understandable if you've seen poorly-made and under-constrained feature-based models fly all over the place. Without an authoritarian modeling strategy, all hell breaks loose. (There's a reason the original developers used the term "suppress" instead of "disable" or "turn off" for features.) After you've used proper, explicit, direct modeling for a while, it's easy to forget that in feature-based systems are constantly doing things you don't expect when you're not keeping a close eye on them. It's hard to imagine a world where you can leave a $20 bill on the sidewalk in front of your house and still expect it to be there in a week. But's that's direct modeling without the contamination of features or constraints.

This is why I'm so baffelled by vendors who try to do direct modeling with features and or constraints. Usually these tools are promoted with some hint of adding more of the benefit of history modeling than is possible with the simple, straightforward direct (explicit) approach. As a professoinal marketing person, I understand the urge to differentiate, but to undermine the simplicity of direct modeling in the process is counterproductive. That is, unless the underlying goal is to maintain the status quo and stifle innovation. Although FUD can be an effective short-term marketing tactic, it makes for a terrible product strategy.

Rant aside, I would love to hear stories about effective ways to capture true design intent.

-Blake
Director of Customer Development at SpaceClaim

Paul Hamilton said...

Good rant Blake. Thanks for stopping by. It seems that the history tree, while it can be very useful in many cases, has pushed product design into some very unusual/unnatural methods for designing and documenting.

Anonymous said...

It's amazing to see the love fest between the two of you! The way you guys go one might think that the world began with history-based modeling, and that you guys are the ones trying to change the status quo. What about the old systems like Computervision and Intergraph's EMS? Weren't they closer to today's direct modeling systems than history-based modeling systems?

My interpretation of top-down is a design process where you go from abstract to concrete. Consider an architect starting with a rough sketch that captures his vision. So in a pre-computer world there would have been a series of drawings, one feeding the next. Each time making the design more concrete. This progression also goes from larger systems to smaller sub-systems. I can see a similar conceptual/abstract bottom-up design process where you first design a critical sub-system, and then build other sub systems around it (like designing a house "around" a well-designed kitchen).

With history-based modeling top-down modeling acquired a new character. The relatively less concrete design of the previous stage had more value now. Designers had skeletal designs with design volumes, characteristic curves, functionally significant workplanes that associatively tied one stage to another. Thus you could make some changes at different points in the top-down hierarchy and see downstream changes. So typically two (concrete) parts did not have relationships to each other, but they were both related to a third "more abstract thing". This directionality gave immense flexibility.

In MCAD systems typically, bottom-up design meant assembling parts that were designed independently. It's much like putting something together with Lego blocks. In an associative sense, individual parts do not depend on other parts or the assembly as a whole.

I believe that in-context design refers to designing one concrete part relative to another concrete part(s). This would have been pretty common in paper-based or pre-associative modeling days. But with associative modeling, it was realized that undisciplined in-context modeling can lead to chaos (and inadvertent cyclical relationships). Hence it was necessary to invent this word, and provide guidance to the users to avoid certain pitfalls.

Regarding "design intent", I agree that it's a greatly abused term that we can do without. When a designer puts a parallel constraint between two planar faces, it's a stretch to call it "design intent". The way I see it you design an associative system you do it with some "degrees of freedom". You would then tweak the design along these degrees of freedom to arrive at something optimal (I don't mean changing numeric values in a narrow sense). I might refer to the thought process behind creating a design that facilitates the kind of design changes you might contemplate, as design intent.

Paul Hamilton said...

“love fest” Nice one :)

Old CAD systems like CV, Integraph, Graftek, Anvil, ME30, and others were all B-Rep modelers. Today’s direct modeling systems are also B-Rep, but back then all we had were global Booleans. Today we have partial Booleans and local ops that make B-Rep much more flexible and improve performance. We also have much technology around recognition – the ability to recognize certain useful characteristics within the B-Rep model. Back then we also had CSG modelers like I-DEAS and CATIA v4. Today’s history-based tools are simply a combination of the CSG tree structure with B-Rep primitives. So I guess none of our technology we use today is very new. Relatively speaking though, direct modeling is still immature. There is so much more we can do with it.

Good Definitions and explanations. Your definitions are very much in line with others I have heard/read concerning top-down and bottom-up design, including Wikipedia. Whoever wrote the Wikipedia stuff states correctly about bottom-up design: “However, "organic strategies" may result in a tangle of elements and subsystems, developed in isolation and subject to local optimization as opposed to meeting a global purpose.” This “tangle of elements” seems to be common with history-based designs as it seems that bottom-up is somehow the “path of least resistance”. Top-down design seems to require very special attention with the history-based methodology, as these systems require a part modeling mode and an assembly modeling mode. Something that is not required with direct modeling.

I agree with your statements regarding the term “in-context”. The term was brought forward by CAD companies to help users be more disciplined in their model development and avoid the potential “chaos” that may occur without the discipline.

What I’m simply pointing out is that history-based modeling doesn't seem to support the natural process of design very well and that without discipline, a distraction to design, “chaos” and “tangle” will be frequent. And to be fair there are aspects of direct modeling that may be unnatural as well – although in my opinion to a much lesser extent. Direct modeling simply doesn't favor or encourage any one of these methodologies over the other.

Enjoy the discussion. What am I missing?

Dennis Nelson said...

I have never really understood, or taken the time to understand, the terms top down or bottom up. I do find it interesteing that while some in the industry are leaving constraints/history behind for direct modelers, other are flocking to the highly constrained, algorithmic modelers like Rhinos's Grasshopper and Bentleys Generative Components. I have seen some pretty amazing stuff being generated with both these products and would love to hear your thoughts as I think they are good examples of history based modeling

Paul Hamilton said...

Dennis, There are certainly many valid reasons for using history-based modeling. Programmatic definition and control of geometry can be a very powerful thing. With proper programmatic control (a good history-tree) you can support things like design variants and generative design (or some call it design optimization). I work at PTC and have seen some of my co-workers also do amazing things with it. What’s interesting about the two use models I mention above is that they both assume that the initial design is done. You have to know a lot about the initial design to describe a variant, or define an optimization study. Where I find people struggling with history-based modeling is in actually coming up with the initial design. Anyone who uses history-based modeling for new innovation or “concept design” or “initial design” knows what “remodeling” is. The chaotic nature of concept design usually yields unusable history-trees. The geometry may be good, but the tree won’t support the needs for design optimization, variants or potential other usage, and as such the design gets “remodeled”.

Someday we will have a CAD system that will allow designers to design with whatever methodology they want; bottom-up, top-down, inside-out, outside-in, or whatever. And then without any duplication of effort, optimize the design and define the variants. This CAD system doesn’t exist yet, and I don’t believe it can ever exist with a technology that is based on recording the modeling operations (history-based). It’s certainly possible with direct modeling, but there’s much work to be done.

Thanks for the comments.

coroto said...

Great post, Paul. It's good to see someone poking at these terms and how they are used. It's funny how they can be used and abused!

Product Design Services said...

Really Great work Paul. Your blog is really informative but it is hard to understand for a laymen. I am a regular reader of your other blogs also. Can you please attach high resolution images with this post to make it more valuable?

Proximo said...

Why do we still use the term CAD? All Design is done by computers or software, so why do we still say Computer Aided Design? Should we not just call it Design.

We don't say electronic toaster because all appliances use electricity.

Just saying

Paul Hamilton said...

Proximo, I think I heard someone at PTC recently say something like that. :) Agree!

Basker said...

Not necessarily relelvant, but will point out that "rocket scientist" is a common but strange term. If you found a rocket in the forest that serendipitously came into existence by circumstances unapparent, and you then studied it and experimented with it, you would be a rocket scientist. But since none of this is common, we generally have only rocket engineers but we call them rocket scientists.

Tomasz Luzniak said...

Paul, is it really last post in your blog?
I hope not, waiting for next..

Tom

Paul Hamilton said...

Tom,
It certainly was not my intention for this post to be my last :). I must get back into it. Thanks for the push.
Paul