Request/Rant: Flush bindings on script close option

Revit
,
1

I’ve mentioned this before, but here’s another crack. We need a way for certain nodes and/or graphs to know that they should not hold onto element bindings for elements created via nodes.

I have regular comments on YouTube as well as people trying to learn Dynamo at work along the lines of ‘my graph is deleting views’ or ‘the graph is moving family instances’.

In my strong and honest opinion, any node that creates Revit elements should not bind the elements to their nodes/graphs by default beyond a graph’s session. It is not intuitive for new and even semi-experienced users, and even I get caught out by it often and curse Dynamo. Nothing feels more stupid than having to tell a user to delete a node that created elements and wire up a fresh one, all because they ran in Dynamo vs Dynamo Player and got stuck with some element bindings. I know and appreciate there are some times where bindings are necessary to achieve a logical script execution process, where some nodes/branches would not intuitively want to re-run in a single graph session. I’m talking once the user closes a graph then reopens it here, generally.

Curious to know if there is any plan or possibility of adding in a graph property in future to tell the graph to flush its bindings, or certain nodes to forget they made something before. For every case someone has justified element bindings to me, there seem so many more where they simply don’t make sense the way they are implemented.

I’ve mentioned it before, but the way Rhino Inside Revit implements this is far better, with the option to choose the binding behavior of these types of nodes. See below the right click option on nodes that could instigate bindings/persistence and how they deal with it from a UI/UX perspective. Incredibly intuitive.

image
image637×431 31.4 KB

My main bugbears are nodes that create FamilyInstances, and nodes which create Views. I think more often than not, these types of nodes should not remember what they created beyond a Dynamo session. I often literally use Python, just to work around this.

Here’s a good example of the nonsensical scenarios they cause, and the difficulty involved in explaining or justifying them to people that encounter them.

I’m aware some custom packages have tools for flushing graph bindings, but I would much prefer see some method where you can flag down certain nodes that flush on close, or a graph property that flushes nodes on close as a graph property Dynamo interacts with. This to me is becoming a fairly crucial UX aspect of Dynamo I struggle to deal with or explain to others, and I’d be keen to see some degree of thought put towards dealing with it in the core of Dynamo if possible. I can make this a git issue if we want, but I’m aware some don’t see it as an issue in the development/support team.

image
image467×457 29 KB

Even when instructed on how to work around it, many users still hit the wall again as ‘whoops, I ran via Dynamo before closing the graph’. Completely unintuitive UX.

I’m aware that the Dynamo roadmap is very heading towards Dynamo as a service, and lowering the entry curve and challenge of using Dynamo with features like enhanced auto-complete, but I strongly feel this feature will always feel highly illogical in practice to users, especially if newer to Dynamo and programming.

Whilst a bit of a rant, it comes from a place of caring for the platform and it becoming accessible to new users in future. I’ve always found this to be one of the things that makes Dynamo more difficult to teach and recommend versus explicitly programmed solution in Python/C#, where what you ask for is generally what you get.

Any input or feedback is appreciated, even if it’s just ‘sorry, not on the cards because it’s more complex than what you understand behind the scenes’.

4 Likes
2

I feel like a broken record on this topic. Starting with bad news first.

  • My second slide from my AU presentation on the topic was a result of a colleague telling me they wanted to revisit the topic and likely would but it’s been 21 releases and 6 years now. Before I started my vacation it is something the team would like to do, but not something which I believe is being actively explored now.

Now for some work around for those who don’t know them.

  • If you want to permanently suppress it, utilize functions as they never bind (something I learned after I wrote the forum topic and AU session) but know this exposes the risk of duplicate elements at scale which (as with any warning) can make models completely non-functional.
  • You can also write a script to clean bindings from files in bulk (I have shared such before in the forum search for “bulk update” on posts I have made for a Python based tool which runs in Dynamo).
  • And if they run the graph in another Revit file the bindings will be replaced with invalid ones (though graphs with bindings will be slower than graphs without).
  • I believe that Monocle or Rhythm or one of the other popular extension packages has an alternative save method which strips bindings when you use it - if not or if it is broken let me know and I’ll try to publish a tool I use before sharing my work.

Lastly I’ll swing it to the positive front there are some slivers of good news for you.

  • The Civil3D team has a feature to modify bindings, allowing saving it in the DWG (so if works in player), the dyn, both, or not at all so we know it can be done and the Revit team might be able to revisit with that work as a guide - however in my early time experimenting with it this also meant occasional unintentional duplicate instances in the same session (admittedly less of an issue in the DWG format) so might still be a bit of added work for the Revit team.
  • Lastly this is also is something which ought not be ignored in the land of DaaS as the same problems we see in the desktop around having/not having bindings persist in DaaS but are actually exaggerated (every millisecond dynamo takes to executes is a larger AWS bill so bindings which aren’t needed cost money; graphs which cost money to return data you don’t need won’t be a welcome benefit; users who think it failed an hit run again or slam on the button 100 times only to find they were looking at the wrong view won’t be happy).
1 Like
3

I guess my point is that those workarounds are fine for experienced users, but most wont be feasible for beginners that will generally be stumper my element bindings for created objects. It just doesn’t seem intuitive to me, and I think we see a lot of topics on the forums caused by it as additional evidence it’s not easy to understand for beginners.

The fact mcneel has demonstrated a pretty viable UX to this makes me wonder what the developers think of that take. If it is what it is, it is what it is - but I feel like it’s high on the list of things I get tired of having to explain to users, only to get ‘and what is element bindings?’, afterwards followed by ‘how can i disable it’?’.

The point re daas and cost of extra data is interesting… gives me hope it may be revisited.

4

Oddly enough when looking at forum stuff and GitHub issues binding issues were at an all time high in 2018, and only see periodic rise (often associated to a school starting to teach it rather than industry adoption). It may be that users who are getting stuck are replying in [YouTube, Reddit, Discord, etc.] instead, but it’s generally down from what the official channels see (or topics which mention it are serving their purpose and people are solving it there).

I do agree that it is a very poorly documented feature (my AU session and the team’s GitHub wiki entry which is aimed at developers are the only areas I know of - even the Civil 3D feature set has to have a separate web page to describe it and I recall that
Being hard to find) and VERY confusing to new users and also old ones. @helena.wahlstrom this would make for a great specialty topic for help documentation, albeit a difficult to trigger as it is more conceptual in nature like lacing where we don’t have a node to click on and request help for.

1 Like
5

A simple notification would suffice. I don’t know if it is possible.

doing things that are ill advised is fun

2 Likes
6

@GavinNicholls Thanks for bringing up element bindings in Revit – it’s something we discuss internally too once in a while, so we get how hairy it can be. While documentation and resources can be helpful, you are right that it will not be very helpful for a dynamo graph consumer or new user.

Recently we’ve again discussed about it when we looked at performance improvements and kicked around the idea of adding Graph properties like in Civil 3D. But it’s more complex and nuanced concept on D4R side. And as @jacob.small pointed out, this can be more costly especially with our shift to the cloud in the future if we don’t get it right. We want to ensure we dedicate the right amount of time and effort to find the ideal solution.

Unfortunately, we have several competing priorities at the moment. This means it’s not something we can address immediately, but it is certainly on our radar.

3 Likes