winglang / wing

A programming language for the cloud ☁️ A unified programming model, combining infrastructure and runtime code into one language ⚡
https://winglang.io
Other
4.97k stars 196 forks source link

Discussion: Allow collapsing and expanding map nodes #5861

Closed skyrpex closed 3 months ago

skyrpex commented 6 months ago

Think of a good approach to this.

Chriscbr commented 4 months ago

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

Screenshot 2024-05-09 at 12 21 36 PM
polamoros commented 4 months ago

Some thoughts:

skyrpex commented 4 months ago
image

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 commented 4 months ago

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

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

Something like this:

image
Chriscbr commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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:

image

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):

image
skyrpex commented 4 months ago

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

image

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 commented 4 months ago

These are the subtasks needed to implement my proposal:

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

skyrpex commented 4 months ago
image image image
polamoros commented 4 months ago

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 commented 4 months ago
image
skyrpex commented 4 months ago

Notes from yesterday's meeting:

eladb commented 4 months ago

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)