Closed skyrpex closed 3 months ago
I imagine when nodes are collapsed, the connections will have to be combined in some way
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
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.
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
Something like this:
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"
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.
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):
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.
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.
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
Notes from yesterday's meeting:
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.
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)
Think of a good approach to this.