Hi All,
When you are making packages to be shared within your office, are there standards or naming conventions that you follow or a structure that you find to be particularly effective? If you have codefied this, would you be willing to share them?
Thanks
Zach
Currently the few people who use Dynamo follow the naming standards for where the nodes should appear in the library.
Other than that we I have been working on something similar to what Brian Ringley outlined once on Twitter. (In graph notation with group colors.) I will upload an image tomorrow.
I think it could be really nice to have a “template” of sorts with a modifiable sidebar with instructions, dependencies, update information, etc.
I’ve not had time personally to work through a template here - but would love the ability to create/modify the home graph as outlined by Brian and John.
I think it’s best to follow the existing naming standards like John’s pointed out, but I also tend to add the package name as a prefix to the node name to make it more obvious where the node came from - there is not hotkey to point out the library location of a node like there is in Grasshopper so this is a way to compensate.
Naming conventions are, to me, only important when you don’t have a robust search method and are relying on the visual scanning of folders, etc. For example; if some names have a period between words, and others don’t then, so long as the search engine can treat them the same it shouldn’t matter. Same thing with the order of search terms. It shouldn’t matter if I search for “Get X” or “X Get”. I should find the same things. Additionally, searching for nodes should look within descriptions if it doesn’t already. In my experience with Dynamo so far the search function isn’t as robust as it could be. Perhaps that’s where the focus should be placed rather than a naming convention.
Hey Greg - I agree that search should be better, but I think naming conventions are still very important.
Your argument assumes that the user knows they want to get X, or that there is a method available for getting X, or that “selecting” or “finding” X is the same as “getting” X.
Also imagine searching “get X” and seeing “getX,” Xget", “get.X” and the mental energy required to decide which is appropriate for your task. This is basically the current scenario in the Dynamo package ecosystem, which is very open and therefore often redundant, and redundancy is confusing.
And not all libraries play well together - for instance, debugging a workflow that accidentally mixes up Rhynamo and Mantis Shrimp nodes is difficult. This is why, though verbose, I’d actually prefer any non-core nodes to begin with the package name.
And consider the intelligibility of a graph lacking naming conventions, particularly when collaborating with others or on-boarding novices. Again, from a mental effort perspective, a lot of interpretive work could be offloaded by a known standard or convention.
Dynamo has democratized design computation, which means a lot of different user types. Different users will search different ways - so the ability to scan a traditional hierarchical library is just as important as the ability to run a search.
Hi Zach, In my naming conventions i try to use the Dynamo version im using. But this will not be suffient. Naming the packages im using inside the graph and their version numbers creates a very long name for a node/graph A popup when loading a .dyn there could be a warning that not all packages used, are the same ones used to create it, and a way to restore this would be nice. So, a check on subcomponents of a graph and a way to get the right versions of Dynamo and the related packages needed would be nice. Naming convention wouldnt be that important anymore or even trivial. Marcel
I have to agree that including the package name(or abbreviation) at the beginning is good. The reason is how would the computer(when using node in design script) or person know they have loaded the correct node in if two packages have the same node name, but may do things differently. Eg one may just get the element while other may get element plus other info as output.
I do think that things shouldn’t be over complicated with long naming conventions and just common sense should hopefully help when naming things.
