Parts vs. Bodies

[MSOlsen65]

I'm not saying that it doesn't make sense to rename the terms, but this is a more complex discussion, and it would require consensus of different developers, and also some refactoring of the internal code. Otherwise we can only do a very superficial name change. Say, we can change the workbench selector to say "BodyDesign Workbench", but internally, everything would still be named the same, PartDesign::Body, PartDesign::Feature, PartDesign::AdditiveBox, etc.

Would that superficial renaming be helpful? Maybe. Or maybe it just introduces yet another inconsistency where the internal code says something and the user interface says a different thing.

I can appreciate the complexity involved. That said, I would suggest that it is a topic worthy of serious discussion as it has strong potential to reduce confusion, and therefore the learning curve, for new users. Something that is very important for the longevity and adopt-ability of any software.

I suspect that the path to follow would be a bit of compromise. For example: Once a change of name is the consensus, then a superficial change to the UI would provide immediate relief to those deciding if the wish to learn or adopt FreeCAD as their 3D modeling environment. This could then be followed by the more meticulous refactoring of the internal code by planned and announced stages. Thus the developers and power users have a bit more time to adjust, and possibly help refine, these changes.

Obviously this is merely one of many possible compromise/combination approaches. I would expect that others, like perhaps yourself, who are closer to the more influential developers/contributors would be able to make a more practical suggestion on compromise. I do not expect an "instant" solution. I would merely ask that the concept be given due consideration based upon its potential to affect the growth of use and adoption -- again a major factor in the longevity and field of influence for virtually all software.

Personally, I am glad we can have this conversation, and for the respectful consideration you and everyone have shown my inquiries, thoughts, and suggestions. It is a refreshing change from many other forums, and speaks highly of the caliber of both the members and leaders.

[vocx]

... I do not expect an "instant" solution. I would merely ask that the concept be given due consideration based upon its potential to affect the growth of use and adoption ...

Well, that's the thing, as a developer, I don't think it's a huge priority. And I think most developers feel the same, otherwise it would have been changed already. Yeah, the terms may be a bit confusing, but this confusion can be solved, I think, with more extensive, and better user documentation. Some users get confused, but after a few weeks of working with the program, it's no longer a matter of concern.

If you had found a resource that clearly explained these concepts, maybe you wouldn't have opened this thread in the first place. So, I personally think that we need to expand the amount of documentation in the wiki to better introduce users to the program. Some core decisions can be discussed later as time permits.

[MSOlsen65]

... I do not expect an "instant" solution. I would merely ask that the concept be given due consideration based upon its potential to affect the growth of use and adoption ...

Well, that's the thing, as a developer, I don't think it's a huge priority. And I think most developers feel the same, otherwise it would have been changed already. Yeah, the terms may be a bit confusing, but this confusion can be solved, I think, with more extensive, and better user documentation. Some users get confused, but after a few weeks of working with the program, it's no longer a matter of concern.

If you had found a resource that clearly explained these concepts, maybe you wouldn't have opened this thread in the first place. So, I personally think that we need to expand the amount of documentation in the wiki to better introduce users to the program. Some core decisions can be discussed later as time permits.

Here I would disagree Vox. There is already a ton of documentation. In fact, you, Chrisb, and others pointed me to what I needed very quickly. However, there was nothing intuitive about finding that information. Strictly from a user perspective, each new name is a new thing (i.e. Part, Std_part, Part Design, etc.) are all separate unique things but are also all related. This has been a fairly consistent norm from the users perspective since 1978 (yes I have been using computers that long. Been running exclusively Linux since 1997).

Unfortunately, another element that has been a consistent norm over that time is that programmers (developers) tend to dismiss the user perspective too easily. Today, especially since 1995, user perspective is actually of major importance. The most successful software ventures takes user experience seriously because they have learned that "having the best mouse trap" is meaningless if the intended users find it too difficult to learn, use, etc.

While such things as clarity in the UI may not be important to a developer, it IS A MAJOR CONSIDERATION for users, especially for those who's income will be impacted by the ease of learning and use. It is one of the major reasons Sketch-Up has had a major impact on the entire CAD industry. They provided a simple, clear, intuitive UI following symbol and naming conventions that the general public has come to expect (i.e. a friendly, clear learning environment). With over 18 years of development (ancient by most modern standards) FreeCAD is still way behind the power curve in this area.

Is it the developers intent to keep this as a "personal play environment", or do you wish to see it become what many users are hoping for -- a real opensource competitor to AutoDesk, SolidWorks, etc.? If the latter, then it is definitely time to listen to honest user requests for clarity so that it will grow in use, acceptance, and adoption, becoming the true powerhouse it is meant to be.

[vocx]

There is already a ton of documentation. In fact, you, Chrisb, and others pointed me to what I needed very quickly. However, there was nothing intuitive about finding that information...

That's exactly what I mean! If we can write the documentation in such a way that you can find the information that you need quickly, then the problem would be solved, or not?

I was able to point you to that information quickly precisely because I wrote it! I am a user as well, and I already identified the need for better documentation (explanations) precisely so that we don't have to repeat over and over the same answers to questions like this. That's what I've been doing for the past year! I've been working on organizing the documentation so that it's simpler to discover, simpler to read, simpler to navigate, etc., but it isn't something that only one person will do. It's the effort of all those who want this program to succeed, not only of developers sitting in their marble towers. Certain developers certainly don't care much about polishing the documentation, the interface, and things like that, so other people need to step up. It's free software, it's the natural order of things. Whoever has passion for this program will join the cause to make it better, those who don't have that passion, won't.

And there is also the issue that no matter what you do, no matter what you write, no matter what names and terms you use, no matter how much you polish something, some users will still be clueless and will get lost. You can write a sign saying "press the button", and some users will still ask "what do I do now?"

FreeCAD is free software and therefore it doesn't have a deadline; the task of making it better does not rest on the developers, but on the users; actually on both, the line between developer and user is in fact blurry.

[MSOlsen65]

There is already a ton of documentation. In fact, you, Chrisb, and others pointed me to what I needed very quickly. However, there was nothing intuitive about finding that information...

That's exactly what I mean! If we can write the documentation in such a way that you can find the information that you need quickly, then the problem would be solved, or not?

...

FreeCAD is free software and therefore it doesn't have a deadline; the task of making it better does not rest on the developers, but on the users; actually on both, the line between developer and user is in fact blurry.

Actually not. As one who has spent the better part of 25 years meticulously documenting procedures, definitions, policies, and histories (US Army retired) , I can attest that clear and well organized documentation is in fact extremely important ; however, clarity of and consistency throughout a user's experience always has, and always will, trump any level of documentation.

You are 100% correct that true freeware has no deadline. It is also true that taking more than five times as long as similar products to reach a level of "not ready for prime time" is generally cause for many, if not most, serious users to ignore or dismiss a project as irrelevant. So no, the line between developer and user is not at all blurry. In fact it is immensely hurtful and insulting to users whenever developers suggest such.

After all, no one expects every driver to be a master mechanic, automotive assembler, or automotive engineer. So why should developers, persons with highly specialized skills and knowledge, get to suggest that they have or experience the same perspective of interaction as common users, persons without that specialized skill or knowledge? More over, why should they get to treat users with dismissive attitudes when the users bring to them honest concerns and recommendations? Without the feedback, the developers only know what their own myopic perspective provides, but buy cooperating with users and others a much broader picture can be seen.

I appreciate the help you provided. I also appreciate your work on the documentation. Both have been important and very meaningful. However, to me, you consistently come across as dismissing the concerns that I and others have brought forth is this thread. You and others have also come across to me as belittling ideas and suggestions of those with fresh perspectives (novice users). While I cannot speak for anyone else, to myself, it is a most frustrating and hurtful approach. I do so hope that such was neither you intent nor inclination, and that we but danced so poorly as to by accident kick each other shins.

[vocx]

You are 100% correct that true freeware has no deadline... So no, the line between developer and user is not at all blurry...

You have no idea what you are talking about. This is not freeware. It's free software. As I said, developer and user are one and the same. It's not a concept that many people understand.

[chrisb]

If you take users on one side and the people who with a commercial product would work for a company on the other side, which means developers and people doing the docs then the border between these in that sense blurry as people may start as users, improve the documentation, start with small python scripts and end up creating a new workbench - and they still remain users.

Besides that, the documentation is not only the wiki. FreeCAD provides highly individualized documentations for single users in this forum. If you see the program and this forum as a unit, then FreeCAD is indeed very well documented and by far not as bad as I read here every now and then.

[wandererfan]

Unfortunately, another element that has been a consistent norm over that time is that programmers (developers) tend to dismiss the user perspective too easily.

My experience is that developers are very happy to build whatever the end users want. They may be prevented from doing so by budgets, schedules, regulations, politics, existing code, conflicting demands within the user group, etc, but for the most part developers prefer happy clients.

With FreeCAD at least, the dividing line between programmer and user is not as crisp as you make it out to be.

Are there many FC programmers who are not FC users? Possibly wmayer and realthunder are too busy developing to be big users of FC, but I am hard pressed to come up with many more names.

Yorik is certainly a user, so are bernd and sliptonic. tpavlicek and fjullien needed something while using FC and so developed their big contributions to TechDraw. I got involved because I wanted to sketch out a bench for the workshop in a new home. The add-on modules were mostly (entirely?) built by end users.

This is not to say that everybody writing code for FC is necessarily an expert in the subject area related to their code. Certainly I have no training or experience as a draftsman.

This overlap between developers and users is a double edged sword of course. I'd love to have a couple of real power UI developers on the team, even if they didn't know beans about 3d modelling or drafting or whatever.

wf

[wandererfan]

And back to the original topic, yes, FC has a big problem with nomenclature. This has been the source of many "spirited" debates, such as this 8 pager - https://www.forum.freecadweb.org/viewto ... gn#p222622

[Zolko]

After all, no one expects every driver to be a master mechanic, automotive assembler, or automotive engineer. So why should developers, persons with highly specialized skills and knowledge get to suggest that they have or experience the same perspective of interaction as common users?

I'm sorry to say it so bluntly: you're loosing your time. FreeCAD's mantra is:

it's done when it's done

which means, translated: "We don't care about whatever you say. We might do it, or not, who knows.".

Fortunately, not everybody is in agreement with this approach.