[Request for Feedback] Dynamo Package External Dependency Filter

[Aaron_Tang]

Dear Dynamo developers and users,

I am back! Thank you for your comments in [Request for Feedback] Dynamo Graph Package Dependency Display which are tremendously helpful. A big round applause to us all doing new Dynamo development together.

Time to share some new progress from our team. If you look back with us together, 2019 is a huge year for Dynamo, we have made it into not only Autodesk Revit but also Autodesk Civil3D, FormIt, Advance Steel, Alias. As a result of the fast expansion and broader host specific users, our team is getting some new challenges. One of those is that, while the number of our host specific packages is growing, how do we make it convenient for package authors and consumers like you to be able to easily publish/ search for/ download host specific packages. For example, currently, Dynamo for Civil3D users will need to search for what they need from a list of Revit packages which could hurt their efficiency. So now, challenge accpeted!

What we plan to do at this point is to add a host filter right next to the package results sort option. This will be a checkable context menu from filter button click. The default option will be All, while user could set this on demand when they are working in a specific host or totally ignore such setting. The impact of such setting is that turning it on will instead of displaying all packages regardless of what host they are made for but display the packages only can run in this host environment. A preview of such UI can be found below:

Package authors are expected to also mark similar info in the publish dialog before our team could figure out smarter way of doing it. A preview of such UI can be found below:

However this filed is not mandatory, if the package author did not set this field while publishing, it will be treated as a generic Dynamo package which will still appear when no host filter is applied.

And now we kindly need your feedback from here

1. Does this sounds/looks like the approach you would like to use?
2. Would you like such host specific filter to persist even after you have closed Dynamo session?
3. If this does not make sense to you, can you suggest an ideal workflow in your mind?
4. Any comments are welcome here and I will be watching this post!

Thanks for paying attention and giving us feedback.

Cheers,
Aaron-

[angelohbwang]

1. Absolutely.
2. Yes. One question is will there be a “General” filter for general packages. For example, for Civil 3D users, they might only want to see all General and Civil 3D packages.
   Other:
   It’s “Civil 3D” (there is a space)
   Are multi-checks supported?

[Aaron_Tang]

Multiple checks should be supported, seems going to be useful in a lot of autocad vertical cases?

[Mark.Ackerley]

Hey,

Really great to see improvements to Dynamo, keep up the great work!

Just to step back a second… Is there a Dynamo road map to see how all these things come together?

Following @ikeough comments about a shift to github, is that the long term aim? With these improvements a stop gap? Or is the package manager seen as the future?

1. For this specific point, I might prefer to have the check boxes outside of a filter dialogue, it saves a click, and makes it clear to see. This is a different situation to the regular node search where quantities of check boxes will vary according to search criteria.

2. Agree with the ‘general’ comment above.

3. Ideally, if I’m in Revit, I would like to see the packages I can use, but have the others greyed out (and a helpful note telling me why), so I know they exist.

Edit: I’m probably wrong on that, as it would make it very cluttered. Feel free to ignore

4. I am not an MEP user, but MEPover has lots of great stuff. Maximising the inter-operability between packages for different software might be very beneficial.

Hope that’s of interest.

Thanks again,

Mark

[Robert_Cervellione1]

1. Makes sense

2. Yes

3. There should be no default when publishing packages to ensure someone makes a conscious decision. Also it would be easy to check the dlls selected for the package and know that it’s revit, cad, and alias specific and make general not an option.

4. I assume this list is only for Autodesk integrations so people who intergrated Dynamo on other packages won’t be able to add to the filter?

[solamour]

Hello Mark,

To specifically answer the Github comment - we are still considering the future direction of the Package Manager from a back-end standpoint! However, regardless of what approach we take there in the future, there will always be an interface inside of Dynamo that the user can interact with The focus of this piece of work is on that.

Cheers,
Sol

[Mark.Ackerley]

Thanks Sol

[Brendan_Cassidy]

This is something that I feel is in the right direction, though i would suggest the following changes/enhancements:

• Allow filtering by dynamo version - This includes filtering out earlier versions of a given package if they are not compatible.
• Allow multiple options to filter because some standard dynamo packages could be very useful to civil 3d, revit, formit versions. These wouldnt be shown if you select say Civil 3d.
• Maybe even filter by “hosted” programs versions(only a thought)?
• Default filters could possibly be taken from getting current dynamo version and seeing if it is hosted or not.

[M.Perez]

1. I find good to have the option to filter, as others said it could be probably even extended in the future. But I guess I would be using this option as less as possible. I don’t have in mind to go through the whole package list, but to look for one package, which name I already know.
   2.No, I would prefer it not to persistent, as I said, having Packages filter would be for me an exception.
2. I would show for each package a list with “supported” or “recommended for” programs. You could even make it green for installed or current program, but not really needed. As I go throw the list, I can see if the package applies for my needs.
3. As other said, I would made category mandatory. If not, the packages will be too oft filtered out, making filter useless.

Just my two cents.

[Aaron_Tang]

Hi Mark,

I would love to follow up on the first comment from you. If our team for example, after you select a particular filter, update the filter icon to be the corresponding host icon so that it is clear, do you think it would be easy enough for you? Or you would totally expect the control to be more obvious than the package sorting control?

Cheers,
Aaron-

[Aaron_Tang]

Hi Robert,

3. Good point, if no package author is aware of such filed then in the end this feature would not be helpful to whomever doing the search. I will communicate with the team about this.

4. We would like to include all hosts, but to your point, auto detection to unknown hosts would be hard if we do not know who they are when they doing either in-process Dynamo integration or even out-of-process one. The bottom line is that people could still at least contact our team to add them as trusted integrator? @solamour @Michael_Kirschner2

Cheers,
Aaron-

[Nick_Boyts]

@Aaron_Tang

if the package author did not set this field while publishing, it will be treated as a generic Dynamo package which will still appear under default host filter All

I think there needs to be a separation here. A few others have mentioned a General filter for non-hosted packages and I completely agree.

I would also prefer check boxes to allow for the filtering of multiple host applications in a single search. This would allow for a Not Specified option if the package was published without a selection, rather than defaulting to All or General. This would allow users to decide if they want to filter for packages that have been explicitly developed for certain hosts or include possible options that haven’t been specified.

[Aaron_Tang]

Hi Brendan,

Good thoughts there. It seems you are suggesting a more detailed mapping between package versions v.s. Dynamo versions v.s. host versions. Can you give me some more to understand where do you come from on this? I suppose you have found our team or Revit team sometimes broke API in the past making packages having inconsistent behavior across Dynamo versions and Revit versions (e.g. 2017 and 2018)?

Cheers,
Aaron-

[Aaron_Tang]

Hi,

Thank you for your comments! I would like to follow up on the “recommended packages theme”. This is one thing I have been thinking about for a long long time and we could totally use some smartness (or Machine Learning) there to suggest useful packages for users. I understand a lot of the time, as a user you already know which package you would like to search for and download. But to be honest, our UI has not been doing a good job to entry level users who would just like to explore. Would you be against making such suggestion out side of the package manager client and part of your daily Dynamo workflow? For example, if our team make a dedicated area for nodes and package recommendation when you are constructing the graph.

Cheers,
Aaron-

[Nick_Boyts]

I think node vs package suggestions are two completely different things.

Node suggestions could be based on the last node you placed (or better yet, last node updated in a run) and would be dependent on node outputs. (The last node has a Point output, suggest nodes dealing with points.)

Package suggestions could be similar to dynamopackages.com - Most Installed, Most Depended Upon, etc. - or even based off your other installed packages. (You have lots of MEP packages installed, suggest other packages with similar tags.)

[Mark.Ackerley]

Hey,

I’d just have the 4 or 5 exposed check boxes at the top… But that’s just me, I’m quite 1980s IBM in my aesthetic taste… You could colour code them if you were going crazy…

Cheers,

Mark

[maciej.wypych]

1. Filtering would be a good addition. But as a separate popup selection, it would be annoying if you forget which filter you’ve applied.
2. No, especially that it looks it won’t be visible after you select it.
3. I’d prefer a set of tags that could be applied to each package (the set should be predefined) These would include each of the hosts, core, version, and could potentially include a few additional tags for specific functionality. Something like this image
   

[M.Perez]

Your image is exactly what I meant with “supported”!

[Brendan_Cassidy]

Aaron,

It was more of a thought to make it more robust towards people that may not know about possible issue areas when new releases are released because of api changes or file format changes.

• Dynamo had a file format change at 2.0 which broke some packages.
• If a packages is via dyf files then this package is built for 2.0 therefor it will not work in prior 2.0 versions. though a DLL package could work with previous versions.
• Similar process could be said for when revit/civil 3d/etc have classes/methods/properties that become obsolete.

All of the above details about a package should really come from the package developers with the package manager helping to facilities people being aware of this then suggesting the correct versions.

Side note: The forum needs a update on categories because there is currently nothing related to the other hosted versions of dynamo.