@jacob.small@solamour The latest Dynamo UI ‘refresh’ seems to have many resolved issues with it. If some of these are due to my ignorance, please let me know. If not, can you please take a look at them so that we can improve the UX.
Main UI:
Nodes are unnecessarily large. Clearning up the layout is a major pain especially since there is no Split canvas (Moses command) like in Grasshopper.
Library text is super small and bloated with unnecessary hierarcy tree arrows.
Turning off ‘show connectors’ is not persistent and reappear when reopening the Dynamo graph.
General slowness. Navigating the UI is far slower compared to Dynamo 2.6 even with minimsed groups and connector turned off.
Delete does not work in library search. Only backspace.
Groups:
Inability to add nodes to a group when that group is minimised.
Minimise and ellispse icons are incredibility small and hardly visible.
If group colour is grey, minimise and ellispse icons don’t change colour and can not be seen.
Trying to delete a single node often results in deleting the entire group. Using undo often results in Dynamo crashing.
Inability to change the text size of the subheading.
Alternate node display:
Zooming out triggers the alternate UI where nodes show their state (frozen, preview off, etc). On large graphs this can take up to 30sec. Accidently zoom in or out, and you end up waiting forever for the UI to refresh. Moreover, when groups are minimised and no nodes are visible, it still takes the same amount of time.
Dynamo player:
Additional outputs seem to be included, even if the nodes have no ‘IsOutput’ enabled. Does this have something to do with errors?
Deselecting settings, like sort alphabetically, does not appear to be persistent.
Using a 2nd screen, Dynamo Player is not ‘always on top’ and not visible.
Believe some of these are discussed here in more depth by users/developers:
There are some tools developed by various people to help with graph resizing and various other upgrade quirks:
Those not addressed here probably are best directed to the Dynamo github:
Personally where I work we just have to segregate all graphs into 2023+ and pre 2022 due to the IP2.7 deprecation amongst other reasons. I also use pyRevit for more broad tools given it has inbuilt support across 22/23.
Yep, I do. Better to begin with a few that have proposed fixes and then build off that I’d say. Node cleanup is addressed to some degree with the tools in Jacob’s post. These threads pop up from time to time and just get buried ultimately, whereas if they’re added to the git they’re at least somewhere more exposed.
I’m not not he product team so I can’t speak directly on this stuff, but I have enough indirect insights to help out. Some of this has been addressed, or is planned on being addressed. However there are bigger more involved projects which have to be undertaken such as the .net 6 migration - if that doesn’t addressed then we won’t have any Dynamo for the 2025 product line. That is a VERY big effort (sort of the AEC equivalent of rebuilding your largest project from scanned PDFs and no content library to work from) and as such some other things may have to take a back seat for awhile.
Gavin was spot on that the github is an ideal place for many of these issues (and you might consider a support ticket for the Dynamo player issue with the second monitor). Generally speaking ‘it’s broken’ means a GitHub issue for Dynamo Core or Dynamo for Revit would be good, and quality of life improvements can go to the wishlist. The roadmap is also a good place to put feature requests/improvements - perhaps even better as that gets some insight across Autodesk products (Civil 3D and Revit and Dynamo feedback can all be aggregated).
I’ll do my best to give some insight/solutions/fixes for each of the bullet points above - feel free to reply in kind.
Text in the library is now zoomable as of 2.17 by holding ctrl and using the mouse wheel; upgrade to 2024. The hierarchy tree is actually insanely useful in using, learning, and teaching and from what I can see hasn’t changed since the days of yellow nodes.
I can’t say I’ve seen this; do you have a Revit add-in or View Extension causing a conflict or a package with the wrong version? Last week I did see some significant slowness when Dynamo/Revit could not authenticate, so you may want to confirm the issue isn’t resolved by changing your network.
This is in the backlog with an internal ticket for producing it; however I would expect it to be a lower priority as it has a work-around (set the run mode externally prior to opening the file) and has less impact than the other work underway (see the roadmap). If you need a graph to bulk set the period timing let me know and I’ll see if I can put something together later.
I logged the github issue for you here; not sure how this fell through - thanks for bringing it to the teams attention.
I can see a lot of added issues by doing this; where in the group would the nodes be placed? What if that pushed the limit of the group or was on top of another node? Likely best to expand it before dragging into the group, which is the intent at this time. If it’d be a huge benefit for you please outline how in the roadmap or wishlist.
Might be a resolution issue - can you submit a github issue posting a pic showing what you’re seeing? My monitor resolution is set to “starting to go blind but was too stubborn to get glasses before immigrating and now has to wait a bit longer to get into the healthcare system”…
I thought of this as a feature instead of a bug, but with a coming build the text (and I believe the icons) change dynamically with the color of the node. Feel free to add this to the ellipse size issue as an add-on when you submit that.
I haven’t seen this - is there any chance you had the group selected as well? For the crash, were you in Dynamo for Revit with Automatic run mode on?
I believe the intent there was to have it at that static size, but it is a good wishlist or roadmap request.
I have only seen this be instant, and I’m already working with some pretty large graphs in 2.18; can you get a screen-recording and submit an issue to the GitHub? It may require some specific hardware and configuration discussions between development team members so that is a better route.
Can you post a pic and a graph showing what you mean?
Player has been updating a lot, but sadly this couldn’t be made into a persistent setting without delaying all the other benefits. As a work-around I added a tool to the bulk updater to automatically rename input nodes with a numerical prefix to ensure alphabetical sorting was always respected. Ideally something like that would make it’s way into core or a view extension, but I think even better would be a way for graph authors to define the sort order with a degree of control which doesn’t require setting the name in a particular way, or toggling a setting in the player interface.
One other thing to the timing issue: because Dynamo for Revit is owned by the Revit team, even if the Dynamo team resolves something in Core, we won’t get an update into Revit unless that team issues an update.
So if there is a UX issue in say Dynamo 2.12 for Revit 2022.1 which drives you nuts (say the in ability to use alt modifiers to access the edit menu as the Extensions menu and Edit menu both use Alt + E) then you have to update to 2023.0 or higher to get the resolution as Revit 2022 is no longer in planned active development, and as such won’t likely be consuming Dynamo 2.13 (or 2.18…), unless a hotfix or security issue facilitates such.
As a result when I see a problem arise I recommend first notifying the development team (GitHub is the best route for that externally), then I start looking into possible work-arounds, if I get something good I develop the work-around, and then share said work-around as applicable. This ensures that there is a ‘path forward’ for everyone who can’t migrate to new builds, while the development team can work on a fix for the next coming versions.
This tool helps with node spacing and a few of the other issues we have run into.
That “discussion that is +4 months old” led to all of the features that we are building into the tool mentioned above. So yeah. Some of the stuff in that thread went off the rails a bit, but it was for a real purpose to make tools to help with the mess the Dynamo team has caused.
I don’t want it to come across at all that I am just a “fanboy” or anything either. All of these breaking changes are wearing on my patience quite a bit.
But rather than just whine about it, I point out the issues (very publicly) and am helping build tools to hopefully make it better.
@Paul_Wintour adding some thoughts/replies in-line below where @jacob.small hasn’t fully summated an answer:
As from Dynamo 2.17, the Library uses WebView2 and is scrollable like other web pages using CTRL + Mousewheel as Jacob said. From 2.18 onwards this is also a Preference to set in Dynamo. Ditto for the Python text size.
I’ve also not experienced this, but want to dig into why you are @Paul_Wintour. Could you please try the steps that @jacob.small outlines and get back to us? Feel free to ping my work email address and if you don’t have it, DM me. It shoudn’t be slower, but rather have parity with what came before (We sped some things up, slowed some down for a net linear result).
As Jacob said, we have this logged as per our previous conversation, but it’s not so far been high enough priority compared to a bunch of other things (The juggle is real ) such as the .NET 6 upgrade project.
We’ll get to it when we can, and in the meantime always welcome community PR submissions to the Dynamo repo!
This indeed is a regression that has now been logged internally with Jira. Unsure how that slipped through, but suspect all testing was done with backspace instead. Note to self to test both moving forward
As a general rule of thumb, we have UX guidelines right now around ensuring the user has full knowledge of what is happening when making decisions. This means working with Groups in their uncollapsed state when doing something to that group. Same reason the Graph Node Manager doesn’t let you set states from it, but rather collects them and zooms you to the node to take action should you want to.
However, should you have a compelling use case and reason why we should reevaluate that we’re all ears!
Do you mean with regards to Groups like below? If so, ellipses behavior can still be accessed via right-click on the group when zoomed out. Collapse and Uncollapse behavior would be as above re: UX paradigms.
The text will dynamically change in an upcoming release, but the icons do not yet. I’ve filed a bug on this one, so thank you for pointing it out @Paul_Wintour!
Any common crash behavior is priority number one for us, so please do send on any logs or additional information that can help us reproduce this and resolve. Typically cases that are ran into by the community are from various set-ups we don’t have in house, so we’ll need to recreate those conditions to trigger the crash to be able to fix it
Again this is not something we’ve come across so far and the behavior should be zippy. So if you can please send through any information that can help us replicate the issue you are seeing so we can take a look and resolve it that would be epic
This is an issue I experience as well. After opening the graph it is quite instant, but after some time it can lag inconsistently. Sometimes it is instant, but it can go to the 5-10s region or after some reruns a few hours of work it can reach 20 something secs. Also connector detaching and attaching is getting slower after some time. Reopening the graph resolves the issue for another few hours.
In these gifs I just opened the graph, no runs yet and you can see the unconsistent refresh times.
Thank you @kovacsv - would you be willing to share these dynamo file? Happy to do so via DM if you don’t want them public. We can take a look at why the performance is suffering
Node scaling - Used Monocle’s graph resizer and it works great. Would have been better if we diddn’t need to use it at all, but at least we have a workaround. Thanks John.
Deleting nodes - @solamour to elaborate, if a node is not in a group ‘properly’ and the node is moved, the node is automatically added to the group. This is expected behaviour. The UX problem is that once added, the entire group is selected, so if you hit delete expecting to delete the node, the entire group is deleted. The solution is for Dynamo NOT to modify the current selection once the node is moved. This seems far more logical to me. Why would I need to select all the nodes in a group?
Right-clicking on a group allows some functionality but not minimise/expand functionality that the carrot provides. This means you have to scroll in to the (very) small icon to minimise/expand groups. Not a problem for small groups/graphs, but a major issue for large files.
Adding nodes to group - I don’t see why this would be so problematic. If adding elements to a minimised group, the nodes should stay exactly in-place. Groups only resizes in the Y-axis, not the X-axis, which in itself is weired. If it is not compressing the extent of the graph, then what is the point of minimising the group. I much prefer Grasshopper’s clusters (which are not the same as custom node!) but I won’t open that can of worms. My main issues is that to identify nodes not properly grouped, I have to zoom-in, minimise, zoom-out, wait for UI to refresh for 30 sec, find problematic nodes, add to group, zoom-in, wait for UI to refresh for 30 sec, and then collapse again.
Zoomable library UI - I wan’t aware of this functionality. I see it is in preferences but it would be helpful if the UI indicated to the user that this functionality exists. Especially for those migrating from older versions.
General slowness when zooming in/out - I have a large file (2300 nodes). Zoomin in/out trippers the alternate node display. On a file this size it is taking 31 sec to refresh (refer video attached). This is absurd and highly problematic given some of the above mentioned issued, e.g. I have to zoom in to be able to collapse/expand a group.
NEW - Updating a note causes Dynamo Revit to crash. Crash file has been sumbitted to Autodesk via the popup. I believe the issue is to do with bullets. Adding a dash creates a bullet but sometimes, not always, it will crash Dynamo on existing nodes with dashes.
NEW Custom properties in Graph Properties - What do they do? They don’t seem to be visible anywhere.
Look into the bulk updater as well; if you’re moving one thing from an older version you likely have a whole set and should start managing on a per release basis to account for the number of changes to both Dynamo and it’s hosts in a rather short timespan.
This makes sense to me - can you add to the wishlist?
Another great wishlist item.
How would you deal with the added node having a location atop a node already in the group? Or are proposing we allow multiple nodes in the same place? Seems like that would be a nightmare.
Reduce the clutter on screen. For compressing large sets custom nodes are better from both a scalability and a supportability standpoint, and moving to those would be recommended.
This appears to be the root of the problem with the slowness… I haven’t seen a graph with that much in it which maintains functionality well… You’d likely get some gains with custom nodes, but not sure that’d be enough… Certainly worth letting the team explore this one in the context of the engine overhaul which is on the roadmap already - can you share the file with Sol and/or I (DM is fine). In a related thought, I’m guessing that at that size navigation is tough in general. Would it help to have a ‘go to group’ similar to the ‘go to node’ function of graph node manager? Or perhaps a ‘mini-map’ to navigate such files?
Can you reproduce in Dynamo sandbox, or just in Dynamo for Revit? Any chance you have the CER number?
They allow users to associate new data into the file, used primarily for management purposes. Stuff like finding the ‘right set’ of Dynamo graphs. They are not currently exposed anywhere in standard functionality, but stuff like gathering all your MEP/Structural/Architectural/whatever graphs into a readily indexed toolset is achievable by associating such data. They also allow a (relatively) consistent way to pack data into the file which you want to associate to the file long term, but don’t need to access often (ie: the associated Revit file for testing graph functionality and the expected test result).
Add nodes to group - Yes, the node just stays in exactly the same place. If it is atop another node, so be it. It is no different to how it works now. Why would groups need special attention?
UI slowness - This is my biggest bug bear and it is frustrating it is still an issue. The file was sent to @solamour back on 4 Nov 2021. His results matched mine, i.e. it was painfully slow. The solution, wait for Dynamo 2.13 to be released. I’m now using 2.18.1 and things have gotten worse, not better. They may have been performance improvements but the UI alternate node display is a car crash and has wiped away any performance improvements.
For example, if every node is in a group and the group is collapsed, AND wire display is turned off, all that is visible is a bunch of couloured group backgrounds. Zooming in and out still causes a 30 sec UI freeze to reclaculate. If nothing is visible, why is it still recalculating?
Using customs nodes may help but I stopped using custom nodes a long time ago. Why? Becuase you can’t debug in them. They work really well when it is a simple API request - getting view templates or all line styles. But for complex geometric operations they are a nightmare. To troubleshoot you have to copy and paste back into the ‘main’ graph to see the data flow. It is more trouble than it is worth.
Alternative solutions - break graphy into smaller graphs. This can work for some scenarios but it is not a long term solution. Some procedural modelling requires all of this information and can’t be simply split up into smaller graphs. And if Autodesk want to push Generative Design an a method, Dynamo needs to be able to handle large, complex graphs.
I have Grashsopper scripts with a 10,000+ components and there is zero UI slowness. I can use clusters to group components and while working in them, data continues to flow in the live document. I can use Hops to reference in external routines to keep the file organised and run in parallel. None of this is possible in Dynamo.
I am not saying that you should make Dynamo more like Grasshopper, but I am saying that if the UI fresh is taking almost as long as running the script itself (with numerous Revit transations), then something is wrong. The simple solution, is a toggle in preferences to Turn off the alternate display when zooming in and out. I know this example probably represent 0.01% of your user base, but perforamce in Dynamo has allways been an issue and it needs to be prioritised above all cosmetic upgrades.
NEW wire error colour - Sometimes, when there is no error whatsoever, the wires turn orange. Moving them resets the colour.
NEW category by name is returning the wrong categoy. This is new behaviour as far as I can tell as Revit 2021 and Dynamo 2.6 didn’t do this. Is this a known issue?
I recommend using Category by name vs dropdowns unless they need to be selectable by user. If new categories come in later builds, they offset the enumerated option in dropdowns. Has been occuring in any build where new categories come into play, R22/23 added new ones for bridges, medical EQ etc.
@GavinCrump yes I am aware of that and that is what I am doing. My point is getting the category “Lines” using Category.ByName return the incorect category.
Going forward please put ‘new’ issues into a new topic, or better yet submit them to the github as issues or to the roadmap or wishlist as feature requests. Continuously adding stuff like this is going to cause stuff to get lost.
Which version of Dynamo for Revit was the category by name issue in?
I’ll submit an Improvement request into Jira for this one - agree the current behavior is odd.
I can also submit an Improvement request in for this one - makes sense to do!
We made the decision to not collapse the groups horizontally in the X-Axis as uncollapsing them could then overlap with a bunch of other nodes in the graph and reduce clarity. Could you please let us know what behavioral choices in the GH Clusters you prefer specifically?
These are mentioned in our blog posts - out of curiosity, do you read them? If so, was it not clear enough? From Dynamo 2.18 there are settings in the Preferences Panel for them that serialize to the .DYN file.
2300 nodes in a single graph? Wow… that’s really going to be pushing understandability limits! Is there a reason you need this mega-graph this way? Noting that every single node in a graph will hold onto it’s results in memory (By design - so that you can use preview bubbles etc. to inspect at every stage), and that rendering elements on a screen does take computer resources. However, we are aware we have scaling issues with Dynamo right now, as you duly noted, and will take a look at doing some Spikes on them shortly.
This sounds bad and we should investigate - do you happen to have the CER number on hand? FYI @Aaron_Tang
Can you check if you have the Show Run Preview option on? The orange nodes show you which nodes will recompute when you hit run (i.e. have been marked as dirty as their data has changed).
want to dig into why you are 
) such as the .NET 6 upgrade project.
CC