Do you have a love/hate relationship with Dynamo’s Search? Did you yearn for it to be better? To do what you asked of it? To just work? To, dare I say, be a joyful experience?
But we need your help to get us there! We need failing cases - and lots of them , so that we can truly validate the success of the new approach to truly ensure, once and for all, that Dynamo Search finally grow’s up and shoots for the stars
The Ask:
Review existing answers in this thread and attempt to not repeat them!
Post in this thread as many examples as you can/want to of failing search cases in Dynamo, at any stage of completion.
Post any conceptual ideas around how you want Search to work. Note: We’ll do our best but may not be able to accommodate them all.
An Example of What We Are Looking For:
Goal: I wanted to Search for the All Elements of Cateogry node, so used keywords that made sense to me of elements and category, but nothing came up
Reason: I expected to be able to use these keywords as they are literally contained within the name.
Generally speaking, I think the search could be improved immediately by doing the following.
Stripping all spaces and special characters from the user-entered search. This would eliminate the disappointment in searching for some examples I listed below. Trusting that a user will always type the exact number of spaces or special characters is setting them up for failure.
Giving priority to the name first. For whatever reason, the description tends to take priority (which is annoying). Eg, delete example
For a similar node (List Create), searching either List Create or List.Create yields correct results. This is not the case with List.Join at this time.
Searching for (just about any node) that has a point in the name is confusing. A beginner user, might not be aware you need the . character. Especially when it does not show in the library view.
In Monocle’s simple search, I remove all formatting from the node names and the search criteria, While converting to uppercase for comparison in the background.
Hey Sol, is this specific to either right-click search or searching the library (left side bar)? Seems like they are probably the same thing, but just want to clarify.
Totally agree on the annoyance - many a search has come up empty when I searched for FilePath instead of File Path…
I recall hearing something WAY back in the day when I was starting my Dynamo journey (2015?) that the search utilized the description as well so that new users who don’t know the node names could find what they are after. The classic example of this would be “Translate”, which no sane native English speaker without a background in computation would ever think to search for, and I’d guess that GeometryTranslate likely wants to be surfaced higher than File.Move based on usage; so there is likely some degree of configuration required. Stripping out special characters and standardizing case likely helps too.
I may be a bit biased, but personally I think that rather than hard coding search priority the library search should be configurable to allow just names, descriptions, tags, packages, classes, categories, or any combination of the above. That configuration should be a held in the active session for subsequent searches, with the initial session configuration setup driven by user preference. In canvas search should inherit the same configurations. This is similar to the package filtering available today, but with the added benefit of stuff being remembered and pushed to all search methods.
Doing so would allow skilled users searching just names, and new users searching names and descriptions but getting results a bit slower, and we can all keep mesh toolkit in the library without having to remember which Icon is for Mesh.Translate and which is for Geometry.Translate by just marking “don’t search this package” in the configuration (reducing the search size and perhaps thereby decreasing search time).
Its frustrating as all get out that different Dynamo versions treat search differently, at the moment. I dont remember which version is which, but to find FilterByBoolMask in two different versions of RevitDynamo, in one i have to search without spaces, and the other i have to search WITH spaces, or i dont find the node at all. This is just bonkers.
In Monocles Simple Search i find it immediately.
Results List: I cant think of ANY reason why- if ive typed an EXACT match in the search bar- the EXACT match is 5 or 6 items down the list. Thats nutty. The first five are close matches, but not exact. All Elements Of Category does this, all the time.
In Monocles Simple Search i find it immediately.
Speed: I never ever ever care about the picture (sorry). They don’t actually add value. What i care about is getting a many search results as possible, as fast as possible. The Dynamo Search is crazy slow, and the speed varies wildly/widely, on different machines and years.
Items not installed: An interesting one (to me) is searching for things only finds the ones on the current machine (which make sense). But it means heading out to google (or the forum) if you need to figure out what package something comes from. It would be sweet if SEARCH was aware of what was in different packages, even if they werent installed. Id love to search for “SetViewTitleLocation” to come up with a result of “Hey thats from Rhythm, but you dont have Rhythm installed.”
Otherwise, when you see a node in a graph in a pic on the internet, all you can do is ask people where it came from. LOL
Can you give the user an option to add hotkeys for search entries to nodes in the nodebrowser. So if i assign “z” to z axis or “fl” to flatten etc i can just click type hotkeyword and hit enter and i get the right node?
Sol great topic and great suggestions from others. The thing that I do not like about the search is my impression that the search will cut results at the end. So if I’m looking for something general, I type the Parameter I will have 20-30 results but I know for a fact that the library has more nodes with parameter. Why is this important? As a mechanical engineer from time to time, I need to create a script for Architects and I need to tackle new field (for me) and I type some general word like “dimensions” and I would expect to see all available nodes related to that word in order to see quickly what can be done with that element and then search just can not deliver that (my impression).
As in similar to ChatGPT’s level of “smart” searching that is more human in nature? Essentially searching through association and returned result, not rule based and hard-coded?
(Element.Pa so that it appears, now I know by heart lol)
This is how the search feels for me. It’s not really a search, it’s a box I type in a series of characters that I have remembered will give me the node I want. Instead of being able to type in some general terms to find what I’m looking for, I have to remember if I need a dot, space, or camelcase, I need to remember which way around the words go. If I’m looking for something new, or something I can’t remember, it’s a process of trial and error searching a few different times to work out what I need to type to get it to show up.
List.Join gives me what I want
List Join doesn’t
Join List does
List.Create gives me what I want
List Create also does
Create List doesn’t
It gets even worse when you add in 3rd party packages to the mix who might use slightly different naming and description syntax to similar OOTB box nodes, so they might not appear at all, or might be the only result depending on what I type into the search.
Another example not mentioned yet is for ‘Select Model Elements’. “Select” brings up nothing, you need to get as far as “Select Mo” for them to appear, but if you forget that “Model” is in there, and just type “Select Elements” you don’t get the OOTB nodes.