Part design and design intent/concept

[freedman]

This was a test of attachment stablity with a datum plane (deactivated).
https://forum.freecadweb.org/viewtopic. ... 1&start=10

[MSOlsen65]

... maybe some or all of the things you propose could be done but I feel like FreeCAD has struggled for years just to be able to make a model ...
... It seems to me like we just got this thing working and now to redesign some of the basic core stuff, it's too much. It's that old saying, if your hanging on by your finger tips it's not a good time to wave hello.

I see the program at a stage of small incremental changes and then wait for a bunch of feedback.

I agree. It should progress in careful incremental steps. All I am saying, is that backwards compatibility has never truly existed in the way it is often used to dismiss various suggestions. The "Sektch on Face" function is just my experience.

As a new user, I could readily see an option in the tool bar that accomplished my goals. The "beginner" tutorials used this function; therefore it appeared as the endorsed method. Later, when I eventually had questions, it felt like I was being called stupid for following the tutorials and using the provided function. As a new user, it was an incredibly confusing, frustrating, and hurtful experience. While I wanted to do 3D CAD, I had neither a need to learn it, nor, thanks to they way I felt treated, any motivation to do so. Hence I left.

I knew then that FC was a good program and would grow. I also knew that people do change and that forum members come and go. So I decided to be patient, watch from a distance and wait.

Today, I am glad I waited. FC has indeed grown, and in general the forum is a vibrant and supportive community. Many threads, like this one, show how dedicated the members are, and how respectful and supportive we strive to be. Discussions can become quite passionate; however, most work hard to understand each other. Ridicule and mockery are generally avoided and discuraged, or even better, replaced with patients, clarification, and guidance. I have made friends here, and I do want to help.

My comments are generally from the perspective of a basic GUI user. They may be a bit simplistic. My understanding of the issues with "sketch on face" for example. Nevertheless, they are sincere, and seek to understand and to improve FC from that perspective.

[freedman]

As we know, in the case of "Sketch on Face" there is a flaw because of the topo naming issue. In the link above I had that conversation with chrisb, I think his conclusion is the best coarse at this time, we teach users how to model in a normal fashion and if the software has a problem, that can be addressed as separate questions or thru research. Granted, that's kind of but buyer beware. Just kidding, I think if users follow the forum for awhile it is obvious.

As far as forum responses I normally take the pirate approach " Take what you can, give nothing back" unless their nice.

[Zolko]

but doing so would "break backwards compatibility" [...] When I mentioned the already existing incompatibility issues, I was thoroughly trounced by several people who argued that they had changed things and now total backwards compatibility was at the core of FC [...] only the grand illusion of backward compatibility has prevented "Sketch on Face" from being the effective tool it always should have been.

while I think that backwards compatibility is an important feature, I don't think it should be taken as a religious belief. Look at MacOS that has gone from the Motorola 64080 to the PowerPC to Intel x686 and probably Arm64 in the near future, they have always provided transition mechanisms. On the other hand, Windows has always maintained 100% backwards compatibility for applications (not drivers !) and that has brought a huge amount of bloat. Or look at PS and PDF and HTML: they are still 100% compatible without any drawback. Or look at Python2 –vs– Python3. Or look at Catia v4 –vs– v5. Or look at the various MS Office file formats.

So the question of backwards compatibility should not be taken as an absolute, but should be something to keep in mind: breaking of older stuff should be managed, not forbidden.

[MSOlsen65]

As we know, in the case of "Sketch on Face" there is a flaw because of the topo naming issue.

Agreed

In the link above I had that conversation with chrisb, I think his conclusion is the best coarse at this time, we teach users how to model in a normal fashion, if the software has a problem that can be addressed as separate questions or thru research.

Angain I agree.

That said, I would also suggest that such "teaching" means either revamping or removing flawed basic User Docs and tutorials so as to direct new users away from known problems in the first place (i.e. replace all reference of "Sketch on Face" with the know working methodology). I would also remove the known source of confusion if reasonably possible (i.e. in this example the option of "Create Sketch" in the Face Tools menu v0.19). These could remain in the more advanced/complete drop down menus or accessed through python, thus maintaining backwards compatibility. However, removing the ease of beginning with a "bad habit" is a simple, and in fact trivial, change that makes a major difference to new users.

I would have greatly preferred learn the "correct method" when reading the User Docs and tutorials. As it is, I learned the wrong method, sketch on face, and am now struggling to make sense of the "correct method". The forum is a huge help, but I have yet to find a good "User's Guide" to making and using either datum or shapebinders. Since using these objects are, and apparently has been for sometime, the correct methodology paradigm, a tutorial on this should be an important update to the User Docs -- the first place users, especially new users, look for answers to the basics/fundamentals of the program. If it is left solely to the forum, then a great many potential users will simply be frustrated and leave simply because they were either taught wrong (the current status quo), or left ignorant of fundamental information.

Granted, that's kind of but buyer beware. Just kidding, I think if users follow the forum for awhile it is obvious.

Why should new users be required to follow the forum just to be successful with the basics? That is what User Docs should effectively, accurately, and comprehensively cover. I can see a user asking for help if something has not been translated to their language, and in those cases when they wish to go beyond the fundamentals. However, for a User of any software, it is reasonable to expect that the User Docs will provide enough knowledge to allow a basic functional grasp of the program.

My definitions of User, Power User, and Developer:

1. User - anyone who uses the program
2. Power User - those users who also make use of advanced features: python coding, writing scripts and/or macros, performing FEM analysis, animation, etc.
3. Developer - those users and power users who actively work to write, refine, or direct code in the development of either the core program or significant add-ons (e.g. new workbenches or macro modules).

As such all Power Users and Developers are part of the User group, but not all User belong to either the Power User and/or Developers sub groups. Further, only part of the Power Users belong to the Developers. It's similar to finger and thumbs are all phalanges, but not all phalanges are either fingers and or thumbs. Some are toes.

As far as forum responses I normally take the pirate approach " Take what you can, give nothing back" unless their nice.

While unquestionably pragmatic, such an attitude is what has lead to so many basic user types avoiding most forums. The "bullies" get into forums, gain power/authority, berate new users, and dismiss user comments, questions, and suggestions summarily. This results in both the forum and the related software(s) earning a rather negative reputation and adding to the more generalized user paradigm that forums are useless for users be cause they only cater to elitists. A response I often hear and witness on other forums, especially pseudo open source ones.

I am very happy to say, that I have not commonly seen such hostility and bullying here. In fact it is generally not tolerated. It is one of the reasons I am active here and why I wish to help make both the forum and FC better. This group is an excellent example of how fiercely passionate people can work together in a decent and respectful manner. Sure we all slip at times, but we also help bring each other back to being cordial. We "shake hands and move forward."

So while your pragmatic approach does work, and in many forum is the only way to maintain sanity and protect oneself. I am glad that such is not currently the case here, and I am wiling to work to make certain it never is.

[MSOlsen65]

while I think that backwards compatibility is an important feature, I don't think it should be taken as a religious belief. ... Windows has always maintained 100% backwards compatibility for applications (not drivers !) and that has brought a huge amount of bloat. Or look at PS and PDF and HTML: they are still 100% compatible without any drawback. ...

So the question of backwards compatibility should not be taken as an absolute, but should be something to keep in mind: breaking of older stuff should be managed, not forbidden.

I agree. Alas your stance is not what I experienced so many years ago. That said, while I have heard the backwards compatibility mantra a few times, I must also admit that in many cases it has been far less and far more carefully used.

Perhaps I still have a few sore points from the past, but I do get a sense that some still believe that 100% is some sort of absolute that must be maintained at all costs. They appear to use this as a reason to not even consider changes to items that have demonstrably been issues for some time.

"... accordingly all experience hath shown, that mankind are more disposed to suffer, while evils are sufferable, than to right themselves by abolishing the forms to which they are accustomed." Thomas Jefferson, 1776

[triplus]

1.) Datums and potentially moving them to the Structure toolbar.

Datums can now be used outside of body. When click the toolbar button, the new datum will be added to the active body by default. If there is no active body, then consider the active part. If no, there just add to root. Note, I just discovered a bug causing crash on creating datum without body, will fix soon. And I'll add them to the structure toolbar.

This is i guess the gist of it. Hence for me personally, if the whole (most of) Part Design would work like that, then the underlying issue, on why i opened this thread, would be considered resolved, for me. As only supporting the Body paradigm, here i guess developers too often think of potential issues and hence try to restrict them in some way. By doing that basically they eliminate a lot of the valid design intents/concepts and that affects flexibility in this regard.

P.S. As datums will be made available outside of Body, have already been testing Assembly 4 offering, and there already is Part container and an Attachment editor, Assembly solutions are in my opinion there already, being predictable and useful at what they do ... I guess for now i will just try to migrate to Part completely. And to see how that goes. By doing that i gain the flexibility, when it comes to the design intent/concept. With datums getting involved i can decide to make more robust designs, when it comes to TopoNaming, that in the end is my choice to make. I have a container alike feature at my disposal, when planning to move things around. On the cons side, for sure i don't have access to some nice current and possible future features, limited to Part Design. For now, that is i guess something i am prepared to do.