BHoM_UI: autoinitializers expose Name property when it is not needed/helpful

[pawelbaran]

Description:

As in the title, autoinitializers of all types that inherit from BHoMObject expose Name property of the latter, which is not always desirable, e.g. in the example below (please do not mind red colour of the component, it is related to #154):

As disussed with @IsakNaslundBh, it could be good to hide the Name property by default as long as it is not overriden in the oM class. This, however, would require going through each oM type and exposing Name where needed, so initial effort needed.

@al-fisher @rwemay FYI

[adecler]

Name should pretty much never be overridden in the oM class. That doesn't mean it isn't being used by the Engine (or by an Adapter for that matter)

[pawelbaran]

Right, but should also pretty much never appear in the UI as it only creates noise in many/most cases. What would be your strategy to achieve that?

[adecler]

as far as I am concerned, no strategy planned. I would argue that I prefer the Name input to be there and not be used than for people having to know that they can add it from the contextual menu.

[pawelbaran]

Speaking to the users, noise and information overflow is often mentioned as a blocker (which is the case for me when I look at the confusion created by Name in the first screenshot). Therefore, having the end user in mind I would rather hide irrelevant information, same as we do e.g. with GUIDs.

However, let's wait for others' opinion.

[IsakNaslundBh]

Name should pretty much never be overridden in the oM class. That doesn't mean it isn't being used by the Engine (or by an Adapter for that matter)

I disagree with this @adecler . Was actually one of the main reason that triggered the whole virtual properties change. We want to be able to override it and add an appropriate description to objects where the name is of high significance, and just not touch it where it is just an additional string parameter you can fill up with whatever. (for structures as example is SectionProperties vs Bar, first being important, second not).

This way, I think it makes sense to only expose it automatically, when it is being explicitly overridden on the class, as that should indicate that "This is a primary property of the object" Not just something I get with the base stuff.

[al-fisher]

I think it makes sense to only expose it automatically, when it is being explicitly overridden on the class, as that should indicate that "This is a primary property of the object" Not just something I get with the base stuff.

Yep - agreed with this.

[adecler]

Happy to go with the majority.
Just bear in mind that, compared to all the other tasks assigned to me, this is extremely low on my priority list. As always, I am happy for someone else to assign this to themselves if they feel this is more urgent than I do.

[adecler]

I am still worried that users will not realise they can add a name to an object simply because they are not aware of the option in contextual menu. Take for example the case of DataViz where a name is going to be useful on any object (regardless of description in the code or not). I feel we are going to face quite a few cases where people create CustomObject just for the ability to add a name.

[IsakNaslundBh]

am still worried that users will not realise they can add a name to an object simply because they are not aware of the option in contextual menu.

Agree to some extent with this worry, and ofc need to make sure the oMs are updated accordingly before pushing this change to the UI through.

Take for example the case of DataViz where a name is going to be useful on any object (regardless of description in the code or not). I feel we are going to face quite a few cases where people create CustomObject just for the ability to add a name.

For this case, if the name is important, cant the name simply be overridden (with or without a description to start with)? Kind of goes in line with the general reasoning we have been having with using interfaces in favour of abstract classes (with the exception of the BHoMObject), so you simply can look at a class and straight away see all of its core properties, without having to dig through the class hierarchy.

[adecler]

For this case, if the name is important, cant the name simply be overridden

What I meant here is that any BHoM object can be pushed to DataViz. The user will potentially want to have a name on the objects so they can identify what they are selecting/hovering when looking at the charts.

[al-fisher]

I get your point here @adecler - name is pretty fundamental and useful (which is why I think we made the decision to automatically expose it in the first place) it is essential for many objects and workflows. However with the virtual override now possible, I probably would vote for simply control on an object by object basis as to whether Name is a deemed defining property and thus should be given on auto initialiser by default.

Across the BHoM we are always going to have the challenge of findibility of so many features.
Adding a name to an object where it is already determined to not be a defining property is akin to adding say customdata and fragments so I think happy for it to be an additional couple of clicks away.

In terms of planning and prioritising - as mentioned above - we should plan to override Name across key objects in each namespace in any case but also first before any change to UI.

[pawelbaran]

I agree with @al-fisher - for types where Name is rather an extra, not core information, SetProperty sounds like the way to go on the user end.

Is this an item to add to the framework workshop agenda, to make sure this is mapped out and planned?