[Request for Feedback] Local References in 'Workspace References'

Hello world of Dynamo! :raised_hands:

We are going to make improvements to the Workspace References extension over the next quarter, enabling you to not only see installed or missing package content and resolve it, but also understand what else your Dynamo graph requires to run on someone else’s machine.

This means local things such as Excel files, CSV files, images, DWG’s etc., and also local Dynamo nodes such as Custom Nodes (.DYF) and local ZeroTouch nodes.

But… we have a problem! We want to know if our three category names make sense :smiley: Below we have a UX design mock-up of what we are thinking:

Workspace References Category Names

  • The category titles make sense to me
  • The category titles do not make sense to me
  • I think I can do better - and am putting my suggestion in this thread

0 voters

7 Likes

The category titles make sense, but I had a question.

For the local definitions portion- will that surface packages that are not found on the package manager or installed by other means?

1 Like

For the local definitions portion- will that surface packages that are not found on the package manager or installed by other means?

This is the plan, yes! :smiley: For example, local .DYF files, or ZeroTouch nodes that you have on your machine and loaded into the Dynamo space.

1 Like

Could we see the path for loaded Packages as well?

For those of us that develop and distribute graphs for internal use, we often have additional packages loaded for testing. It would be nice to confirm that the packages in my graph are all coming from a public location and not my local testing folder.

5 Likes

Good suggestion Nick :slight_smile: We can wrap that in as well.

Amazing new feature! Love the Workspace Reference addition to Dynamo (and this update)!

1 Like

Love this feature already ! Thank you.
Wondering if it can be integrated into Dynamo Player too ? This would be really cool to our Dynamo users.

2 Likes

That would actually be nice. Not necessarily a full description of references and paths, but a check to make sure you have all the supporting files before you run anything from Player.

2 Likes

Wondering if it can be integrated into Dynamo Player too ? This would be really cool to our Dynamo users. @a.halim

That would actually be nice. Not necessarily a full description of references and paths, but a check to make sure you have all the supporting files before you run anything from Player. @Nick_Boyts

Dynamo Player is currently being worked upon to improve (Starting with back-end refactoring) and will seek to improve this exact experience. It’s a little tricky as the Dynamo Player uses the Dynamo CLI (Command Line Interface) to execute Dynamo graphs - which is headless - so none of the UI features, Workspace References included, will show up.

@nate.peters and the Player team are looking closely at how to unify Workspace References and the GDiR ‘Pack and Go’ experience as we speak.

5 Likes

Would it be possible to have a warnings dialog box pop up that says something like “Not all necessary items are present. Please open the file in dynamo for more information.”

1 Like

Definitely sounds possible to do that :slight_smile: The only thing we can’t access is the UI features, but the packages are serialized into the DYN file.

Not necessarly something I would want. Too scared it would mess up CLI style of running dyn scripts like in pyRevit. Popup are already a nightmare in Revit for any addin software developper, so let’s not bring that into Dynamo, please.

My 2 cents,
Good idea in general, I am not so sure about the naming:

  • Workspace References, it feels like Autocad :wink: . End of the day the workspace is a dynamo definition or a script. Nobody calls it a workspace. We share Dynamo Graphs, Dynamo Files, Dynamo Definitions, not workspaces. I’d rather go with something like Graph References
  • Packages, fine, same language as in the rest of the UI, External Packages,
  • Local Definitions, not sure about that one. It could be: A custom node or local zero touch nome, but also a local zero touch set of node therefore a package. Why not Local Packages, that makes it more inclusive imho
  • External files in this context does not make sense to me either, what can I do :roll_eyes: . They are external to the dynamo environnent, I get it, but they probably are local resources that are missing (or not). Extra files , they are not dynamo related and we do not qualify them as external as opposed to internal.
    :man_shrugging:
1 Like

True. But adding a package is modifying your core Dynamo workspace - new nodes are added to the library.

You are right @JacobSmall . I think a visual graph would help structure the terminology :slight_smile:

Hello @Jean-Marc - thank you for your 2 cents :slight_smile:

On the whole great suggestions - here’s a few comments:

  1. Workspace References is the name of the overall extension that was released in previous versions of Dynamo. Understood that it feels a little AutoCAD-y, but it also thematically fits the notion of where you work inside of Dynamo. To rename to Graph References we would have to trade-off the existing cost of how users see, use, discuss and understand it today versus a renamed state.
  2. The reason we have Packages vs. Local Definitions is that locally you don’t need to have created a package and can have floating DYF files. Any content on the Package Manager is by it’s very definition a Package. Either way we’re a not fully capturing the state of play in a single title - it’s either a local package or local loose DYF files and neither name matches fully. Bit of being between a rock and a hard place on both these names unfortunately.
  3. External Files is a common pattern in software, speaking as you note to content external to Dynamo itself.
1 Like

@solamour

  1. There is no issue with rebranding stuff usually @Autodesk _ me thinking out loud B360 :rofl: Sorry I could not help myself and I do get the argument. It is a trade-off historically talking but would make it more comprehensive on the long run.
  2. yeap!

@JacobSmall

adding a package is modifying your core Dynamo workspace

Indeed. And it is a bit late to talk about the whole architecture of it. Packages are great as it allows you to add a lot of tools / blocks to your library of tools all at once. But the version management is a pain. Stuff like orkestra allow you to manage it somehow. But managing it for a whole remote team without a vpn->server access and with the ability to add whatever package whenever to its dynamo library has been a pain point from day one. We always find ways, and the workspace ref extension addresses some of it which is a step in the right direction, but the actual ways are painful to say the least. Right now I spend more time debugging dyn graphs due to package or dynamo/revit version hiccups than making actual graphs to improve workflows :man_factory_worker:

1 Like

≥ But the version management is a pain… Right now I spend more time debugging dyn graphs due to package or dynamo/revit version hiccups than making actual graphs to improve workflows

@Jean-Marc - We are aware of the issues and have made some tracks in helping on that front over the past year or so (Verbose error messages for the top 30 most common errors, extended documentation frameworks etc.) and have more planned. The Workspace References extension is indeed a step in the right direction, but only the first step of many :pray:

We are improving said extension and thinking more holistically about how to better deal with dependency and version conflicts in Dynamo.

1 Like