Allow collapsing and expanding map nodes

[skyrpex]

Think of a good approach to this.

[Chriscbr]

I imagine when nodes are collapsed, the connections will have to be combined in some way

[polamoros]

Some thoughts:

• Add a button on the map action bar to collapse/expand all the container nodes

• What should we do with connections that go to an inner resource?

• How should we display a collapsed node? I imagine something like this:

• Should we hide the collapsed resources from the tree? For example, the bucket in this case: If we don't hide them, and the user clicks on one, I would expand the parent resource

[skyrpex]

In this scenario, I believe the node c should be always displayed, since it isn't really abstracted away by b but contained hierarchically.

In fact, I believe the construct hierarchy should be less preeminent in our map view. I don't mean removing hierarchy altogether but use the pseudo containers I created some weeks ago. There's also this idea of mine of being able to display some resources more than once, in a special way (e.g. 50% opacity), if the layout becomes simpler that way. Of course, the user would still see that with the resource ID that it belongs somewhere else. I'll prepare some mocks... maybe we could discuss it during one of our meetings.

[polamoros]

WIP

We have two proposals for the collapsing feature:

Add the ability to collapse container nodes. We'd have buttons to collapse/expand all nodes, and a button on each container node to collapse/expand it individually.

I think this will look quite good in small applications (even though it causes jumps on the map that can't be easily fixed).

https://github.com/winglang/wing/assets/5547636/5f5823e0-9ec0-4798-9e7f-79731985ec41

In larger apps like wingcloud, it doesn't help much and the UI jumps will increase

https://github.com/winglang/wing/assets/5547636/5bd64bab-fdb3-456b-914e-6300dd27c2d4

2. Expand the node on another layer, on top of the map (@skyrpex proposal).

Something like this:

[Chriscbr]

I like the first approach, though I can see how the sudden jump when the UI layout changes when you expand or collapse a node could be jarring. It could be nice to have some smooth animation when the nodes change layouts, but I'm not sure how hard that would be to add.

The sub-map idea is also interesting (not sure how I feel about using a modal). Another related user scenario could be "when I click on a subtree on the Explorer tab, then I'd like the map view to update so that only resources within that subtree are displayed"

[MarkMcCulloh]

Expand the node on another layer, on top of the map

+1 to this idea if we can avoid the modal (as Chris mentioned). I think it's very common to only be interested in a subset of an application at any given time, maybe with breadcrumbs at the top to go back higher in the hierarchy. I can imagine even wanting to send someone a link to a subtree instead of the whole app.

This feature could probably co-exist with collapsing/expanding nodes since they kinda solve the same problem but on completely different orders of magnitude.

[skyrpex]

I like the first approach, though I can see how the sudden jump when the UI layout changes when you expand or collapse a node could be jarring. It could be nice to have some smooth animation when the nodes change layouts, but I'm not sure how hard that would be to add.

The problem is the possible total rearrangement of the nodes. We can suggest ELK to keep previous node positions with the interactive mode but not sure how well it holds. We should play with that feature a bit.

maybe with breadcrumbs at the top to go back higher in the hierarchy.

That's exactly the idea, like what Unity folks do. Let's say UI Canvas is our class that abstracts some other nodes through inflight API:

Then, we can dive in inside of UI Canvas (notice the header change in the tree, the breadcrumbs in the map and the buttons to go back):

[skyrpex]

I imagine when nodes are collapsed, the connections will have to be combined in some way

Yeah... I feel like we don't need to display the inflights in the default map view. A simplified relationship (one relationship max between two nodes) helps by removing clutter.

Now, we could offer an additional view (called flows, maybe?) that show the inflight relationships of nodes. Kind of related to traces. But it deserves its own discussion.

[skyrpex]

These are the subtasks needed to implement my proposal:

• [ ] Implement context header in Tree view
  • [ ] Gray out hierarchy items that are invisible in the explorer
  • [ ] Double click on invisible items changes the context to the parent
• [ ] Implement context header in Map view
  • [ ] Implement breadcrumbs
  • [ ] Keep previous map visible, faded out in the background
• [ ] Compute subtree when inside a context
  • [ ] When inside of a context, direct relationships to outsider nodes must be shown too

None of the tasks above are hard to implement, but some refactors may be required to wire everything together.

[skyrpex]

[polamoros]

Just for the record, this is how the WingCloud map looks right now

https://github.com/winglang/wing/assets/5547636/68612d2f-6527-4532-8e1e-ec21883c5a08

[polamoros]

[skyrpex]

Notes from yesterday's meeting:

• List of resources by type would be useful
• Command bar to search
• Allow customizing the levels of detail (1 = hide all child nodes, 2 = show direct child nodes but hide deeper children, etc)
• Maybe use an algorithm that uses the number of resources and connections (e.g. if there’s more than 10 resources, hide the implementation details)
• Distinguish between the logical map view (simulator) and the infrastructure map view (tf-aws). They are different and will have different amounts of resources
• Yoav:

Hey, two visual thoughts regarding how to show that the outer Function is accessing to the inner table of MyBucket in your example, without showing the inner Table:

You can add a hole :hole: and make the arrow point to it, hinting it's directly accesing something inside MyBucket

You can make the arrow fade out inside MyBucket hinting that it's not really pointing to MyBucket but rather to something inside it.

[eladb]

I would keep this project contained and go for now with the in-place collapse/expand instead of the layers. It's more incremental and something that can move us forward faster without a huge investment (the layers are going to require a major ux design$.

Basically I vote to implement option 1 proposed in:

https://github.com/winglang/wing/issues/5861#issuecomment-2134999984

One thing I would add is that if I click to expand a node, the view should zoom in to show the expanded node.

I also suggested in the past that when a node is selected, the view will automatically zoom to show it. It will dramatically improve the navigatability of the map.

Let's keep this as incremental as possible because major ux changes now are going to take too much time and we need this capability asap.

As a separate issue we should discuss search (command + P)