As part of the Dynamo Visual Refresh we are looking to improve how you can navigate node states inside your Dynamo graphs.
We are currently iterating on User Experience Mock-ups of this extension, and would love your feedback on them Please note, these are not finished and will most likely change before landing.
Extension Intention: Give you a better way to navigate all of the node states within your graph from a central extension; Error, Warning, Info, Active, Inactive, Frozen, and Function.
Why are we making this: So that you can see, at a zoomed out graph level, the overall state of your graph; where there are errors, how many warnings, what nodes are returning function states etc.
Option 4: Graphical tags. Each in their own column.
Please vote on your favourite, and tell us in the thread below⌠what resonates? Why do you like your preferred option? Is there any option we are missing? Anything you donât like? Mock-ups of your own encouraged!
Graph Manager / Node Status Extension Direction
Option 1
Option 2
Option 3
Option 4
0voters
Extension Proposed Features:
Collects every node in a graph and displays various node states
Enables you to search and filter the node list based on these node states
Enables you to export the results to Excel
Will collect a âquick viewâ count of all node states in the lower right (Same horizontal line as the run bar) that when you click will cycle through nodes in that state.
Will also create a clickable link in the messaging next to the run button (As well as introduce an Errors message that takes hierarchical precedence). You will be able to open the extension from here, or via the Extensions menu.
Will the filter have capacity to filter to just a selected node state, first instance of a node state, package, category, if the output contains null or [] and node name?
Individual columns for State, Status, and Issues makes this way easier to read in my opinion. Text vs graphics doesnât make much of an difference for me but some sort of colored identifier (text, icon, border, etc.) for at least warnings and errors seems important as those will likely be the higher priority node states.
This is great, but will there be any additional interaction with the node states directly from the extension? For example: toggle Active/Inactive, Freeze/Thaw, or hide warnings?
@jacob.small we are still scoping the extent of this. Not currently going to hook up to the node outputs, being more focused on Node States. This could very quickly baloon into many things.
Do you think output parsing would fit here, or would it muddy the waters?
In my mind the Workspace Reference extension would be enough to cover package issues. I donât think Iâd need to see it in multiple places. First instance of a warning for nulls or empty lists would be nice, but if the nodes are listed in execution order that might be enough.
My thought was that by allowing a filter for just a given package you can see if you have one package causing all the nodes with a warning or info state (ie: this has Python 2 stuff) or many packages on a per graph basis. This would facilitate review and planning of package management for larger firms. It helps to know âwhat packagesâ, but equally if not more importantly is âwhat packages are problematicâ.
Full output parsing isnât a requirement per day, but the âproblematicâ data types of null and empty lists are the root cause for a lot of issues. Doubly so when some nodes returning null intentionally but not surfacing a warning. Everything thereafter will fail and novice users wouldnât know that the resulting null is the root cause.
I think the beauty in the way this is presented makes it feel like âanother way to see my graph at a high levelâ, and merging with things like TuneUp may actually simplify the experience for users, and so I may be over reaching. But to me of the team is exploring a second way to list all nodes on the canvas and report back information about them⌠why not do double duty with one extension, simplifying the user experience, the development maintenance, and the end user deployment?
I get you now. I immediately went to missing packages but youâre talking about missing or otherwise unhandled references within a loaded package that results in broken nodes. That could be helpful.
I also agree that there needs to be some sort of way to identify âvalidâ node outputs that result in all nulls or empty lists and cause warnings later on. Donât have any opinions on how that should be handled at this point though.
Yes, doable. But in that case, since there will be more columns per node, design needs to be updated and maybe we want to let the user pick which column to expose. Or on the other hand, if we want to expose all the info including runtime + node state, then we need a more consolidated UI.
Will the results be able to be retrieved by the API? I have a VE a little similar to this (without UI) that collects warnings/errors in the workspace and pushes to a DB so we can monitor the health of our deployed scripts.
@solamour, sorry if it was mentionned above, did not have time to read the whole thread, but while clicking on the icons, letâs say the warning one, will it give a window listing all warnings texts, nodes outputs and nodes name / origin ?