Fusion360: Diagram of the Conceptual Model

[mikLamming]

I often get stuck because I don't understand the subtle differences between the various conceptual objects in Fusion360, what properties are associated with them, and therefore what operations I can apply, and the scope of their action.  For example some properties carry across a "derive" and some seem not to.  But this is just one of the many mysteries with which I grapple.

The deeper I get into the parametric modelling aspect, the more difficult I find it to predict how a change in a basic parameter of my design  (e.g. the number of replicants of some derived object, and the joints between them) will actually manifest in the composite design I am modelling.  There seem to be no end of hints and tips for achieve a particular effect, but I feel the need for a fundamental explanation of the data objects, their properties and scope, and how they can be composed.  I feel sure there must be a diagram somewhere that expresses Fusion's internal data model, but I'm guessing that I am not generating the right search string to find it.

[TrippyLighting]

For obvious reasons, the internal data model of Fusion 360 is proprietary.

It also isn't needed to understand the general concepts.

If you can share a model and explain what you are trying to achieve we can use that model as a basis to explain concepts.

[jeff_strater · Accepted solution]

I think I get what @mikLamming is after.  I'm not sure a diagram, even if one existed, would answer your concerns.  I understand the question - there are lots of different object types in Fusion, and they behave subtly differently.  Bodies and Components, for instance.  There has been a lot written about the difference between just those two items, but that is all pretty isolated.  The example of Derive, though, is probably not a great one, because there are no underlying principles at play there.  Derive is continually evolving, as more and more functionality gets added.  The same is true with Edit in Place (more and more operations are becoming supported in that environment).  But, there are a handful of concepts that, if you understand them, can really expedite learning Fusion.  Hmm...  I can't promise anything, but I may try to start such a document and see where it leads.

[TrippyLighting]

---

@jeff_strater wrote:

 Hmm...  I can't promise anything, but I may try to start such a document and see where it leads.

---

I think I know what he's after as well. If you want to start a google docs document I would consider contributing.

Putting that much effort into a single and usually short lived thread  is not the best use of time .. for me at least 😉

[mikLamming]

I thank you all for your responses.  Permit this old geezer to suggest an egg-sucking technique to Grandma.  This is not a flame, but an attempt to explain what I think is a possible fundamental omission in the F360 design process.



I wasn't talking about the data model, I was discussing the conceptual model: the mental model that UI designers try to provoke users to form, so they, the users, can efficiently predict what operations are applicable, and what effect they will have on the structure.  As we all know from that UI-101 class, Conceptual Modeling  is arguably the starting point for the design of each new generation of a system.  We learn it is the most challenging part of the design process, but is usually left as a system-to-user-gasket adjustment after the engineers have done their magic stuff.  I am not saying that's the case for F360!



Nevertheless conceptual design drives what must be made apparent to the user,  and where, and when.   Everything else: the command language, modes, visual representation and so forth flow from a clearly communicated conceptual model. 



Some interactive systems (e.g. a very basic text editor?) mimic, or extend well-known real-world models of a typewriter.  But their internal data model may simulate the conceptual model with a data model that may be arcane by comparison.  Taking text editing as my example, with a clearly understood conceptual model, consistently presented, users can, almost without explanation, be tempted to guess properties like text flow, font, most-likely operations available in a given context, and the resulting new document structure they might build if they use a particular command,  phew!  And all this done often without the need for a manual.  



A CAD system is a new beast without close analog in the real world upon which to lean.  Because it implicitly proffers objects, concepts and operations beyond the real-world experience of most users, it places a huge burden on the UI designer. So the UI challenge is to communicate the arcane new concepts in as blatant and streamlined a manner as humanly possible.  Otherwise the user will become frustrated, and turn elsewhere.  



I think the idea of writing a document that lays out the F360 conceptual model is great. But I suspect a succinct notation needs to be devised to describe the conceptual objects and their relationships.  It was this design document I sought.  Perhaps it doesn't exist. I'm sure it would be an excellent precursor for understanding where the obvious challenges to communicating the conceptual model reside, and for communicating said model to noobs like me.  It also might reduce substantially the number of highly specific tutorial videos that new releases make irrelevant.