Better support for "collapse for visual clarity" workflow

Reality.Stop() 2 years ago updated 2 years ago 0

We discussed on the discord that the Bolt 1 ability to collapse a collection of logic down to an embedded super unit in the parent graph for visual clarity doesn't exist as-is in Bolt 2. For such a small use case, we both agree that it's waaay too much work and complexity for such a small feature to reintroduce it in Bolt 2.

(before you realized I was trying to discuss alternative solutions to the problem, you enumerated the following list of reasons this it would be a Bad Idea for embed graph reintroduction)

Here's my summary of the issue.

The problem statement is: single-use graphs that the user wants to collapse take an additional 16px high line in the Explorer window when their parent class is expanded.

The solution to that would be:
1. Allow flow graphs to be embedded, like state graphs.
2. Rework the following UX elements to support that:
2a. Creating an embed graph from the Explorer (3x variations for each graph type)
2b. Creating an embed graph from the Fuzzy Finder (3x variations for each graph type)
2c. Collapse to an embed graph from the Collapse dialog (3x variations for each graph type)
3. Rework the following runtime and editor classes to add the notion (or variation) that the referred graph is embedded:
3a. FlowFunction, FlowFunctionUnit, FlowFunctionEntry, FlowFunctionExit
3b. FlowMacro, FlowMacroUnit, FlowMacroInput, FlowMacroOutput
3c. FlowBehaviour and Activate/Deactivate/Toggle/IsActive*_Units for it
3d. All the Descriptor, Widget, Filter, Generator and other editor decorators for all these classes
4. Refactor the additions above so that the code is DRY and maintainable; introduce a layer of abstraction on the graph source: either class-owned, or parent-graph owned, but it doesn't matter.
5. Provide additional UX for operations that would become common with embed graphs
5a. For example, converting from an embed graph to a class graph
6. Rework the terminology and workflow so that new users are not overwhelmed with choice when creating a new graph.

That seems like multiple weeks of works and very likely higher confusion in the overall design just to hide an Explorer line away, so I'm against reintroducing the embed graph feature. tl;dr: The cost-to-benefit ratio is way too high

I wish you'd had a chance to read my description of the problem, and proposed solutions, as I could have saved you the effort of writing that, as I agree with that and I'm trying hard to help you smooth out this workflow choice without introducing additional complexity. The existing collapse button in Bolt 2 is SUPER handy. Amazingly awesome for taking a complex maw of spaghetti and turning it into something sane, but it currently comes at a cost. I can mark those functions as private, but I don't have any way of toggling their visibility in the explorer. For complex code, this leads to either sprawling monster graphs (just using groups) or sprawling class definitions (collapsing to single use functions). I think it's alleviated somewhat by having smaller classes in general going forward, but I think it's worth thinking if there's an easy solution that allows you to not compromise on your direction.

I can think of two ways to improve this, using the existing windows, and not introducing anything crazy like ANOTHER type. One is just to add or extend the filter button to give control over whether privates should be shown in the explorer.

To which you responded:

Yeah I like the if:public filter idea on the Explorer, it's just not that easy to implement because it needs a different search result display to avoid flattening the hierarchy.

The other option I can think of is to give the user the ability to just outright turn off showing the item in the explorer, perhaps with a "Show in Explorer" toggle right here:

This didn't garner a response at the time.

Bolt Version:
Bolt 2
Unity Version:
Scripting Backend:
.NET Version (API Compatibility Level):
Bolt 2