Another thing about the library that bugs me is the fact that clicking on Revit main category, causes all of the sub categories to be opened as well, and if that was not enough, the Selection sub-sub-category gets completely unrolled for us. If that was done because the thinking is that selection nodes are the most commonly used ones (and you can back that with usage statistics data), then I am fine with unrolling that sub-section, but why all others? It makes users have to SCROLL a lot to get all the way down to selection.
@mjkkirschner @kronz @Racel
2.0.0
Win10
@ksobon thanks for these reports, for this one specifically can you add a gif of the behavior?
I know @ramramps added some behavior recently so that top level categories would open, but maybe the revit categories were not tested and are acting incorrectly.
Yes, definitely too much scrolling. I think the Selection nodes are visible because Selection is the only Revit subcategory that doesn't have any sub-subcategories.
Would it not be enough to just show the next level when clicking on any category or subcategory (instead of the the next two levels)? (Strangely enough, the Display subcategory already works like that...)
Also, I noticed that subcategories that were manually collapsed will be expanded again when selecting a subcategory. Example: Open Revit category, collapse all subcategories, open any subcategory, notice how all other subcategories just expanded again. Again: Too much scrolling.
@andydandy74 why are we assuming that we know what categories/subcategories users will want to open anyways? I think this came up when we were discussing "discoverability". These libraries are massive, and categories like Revit will have many sub-sub-categories making it hard to find stuff. This is not making it easier. We compromised ease of use, to achieve something that is at best questionable to improve discoverablity.
On the topic of discoverability. I think i know what people that are really into tabbed menus on top of the page are driven by. One can easily stuff more things into a tabbed menu, and make it easily available, rather then the left side bars which require scrolling/unfolding. Mhmmmm.
Me and @Racel had some discussion about this behavior. All the section level sub categories are set to open mode and Revit nodes falls under such category. We had a discussion to rollback this feature. We will keep you posted.
@Racel @ramramps @mjkkirschner I think we had this discussion many times, I still believe our library should just behave like other libraries, clicking leads to expand or unexpand, no auto-expanding or auto-unexpanding.
this should be fixed now - but not in dynamo yet, right @ramramps?
The fix is underway.
@ksobon @andydandy74 - Yes, we have reverted the changes that we initially made for the Core OOTB nodes. Unfortunately, the Revit nodes and their categories were no fully recategorized as those nodes and we ran into some complications with how they appear in the library. The next daily build should have the revert, but we will keep you posted. We hope you can test and let us know what you think.
Also, want to get an opinion on something. What do you think of moving the entire Revit category into the new "Add-ons" section. This is something we have discussed as these nodes are not Core nodes, and we potentially have other clients (Alias, Advanced Steel, etc) that don't necessarily belong in the Core OOTB section of the new library. Let me know what your thoughts are.
@Racel - I would argue that as long as DynamoRevit is not an actual package that I as a user can install/uninstall via the package manager, I would not want/expect it to appear in the Add-Ons section. Also, when we talk about DynamoRevit nodes (e.g. on the forum) we do refer to them as OOTB nodes. To preserve that distinction and emphasize their special status over user-made Revit-related packages, I think they really belong in the top section of the library.
@Racel can we close this now?
Yes. This has been fixed. Closing.