Totally agreed. I’ve had to explain “Fiducial” on several occasions - always gets a quizzical look. Either Point List or Landmark List (following @pieper’s Title Case) would be much clearer.
I like “Point List” because it is similar to other markup types - line, curve, plane, etc. and does not assume any particular use. A geometric primitive has multiple uses (point can represent a fiducial marker or an anatomical landmark; a line can represent a distance measurement ruler or caliper, or an axis of rotation, etc.) so it makes sense to not name them based on one specific use.
I would prefer “Point List”, as indicates that order of points matter; in contrast to “point set”, which often means that the items are unordered.
Changing class names and code strings would be disruptive but changing the display name from “Fiducial” to “Point List” should have minimal impact.
1 Like
I support “Point List” as yes we use this node type for placing locations to move our motion stage to, so it isn’t always for Landmarking purposes.
1 Like
Just to chime in, I like Point List too. It is good timing for such a change before releasing Slicer 5.
I tend to agree with @jamesobutler that “node” may be too technical, but still I think the users know what they are (it can be seen in many places in the UI), so adding “node” to the end of the delete action text would make things more explicit.
As it relates to “node” being too technical I say that because multiple of our users had previously asked “what is a node?” when we had some mention of it. I had to explain that it essentially just meant “object”. So we changed from saying “creating a line node” to simply “creating a line”.
If there are places in Slicer that say “node” in the GUI those should be removed. I know in the Segment Editor module the main combobox objects at the top are “Segmentation” and “Master Volume” which don’t have “node” mentions even though technically it is a node selector.
We should try to avoid using “node” in the GUI as much as possible, but I don’t think it is reasonable to ban it. For example, It would be not easy to remove “node” term from everywhere in Data module and anywhere where we collectively refer to different types of nodes or we don’t know the exact node type.
I agree that “object” would sound less technical, but it would be confusing when it is used for constructs that are not physical objects, such as a parameter node, display node, storage node, unit node, selection node, interaction node. “Object” is also a heavily used term in programming, so it would be hard to talk about how to use methods if the inputs/outputs were just objects. If we used “object” on the GUI and “node” in the API then it would complicate things.
To follow up, there was a PR created that includes changing “Fiducial” to “Point List”.