enso-org / enso

Hybrid visual and textual functional programming.
https://enso.org
Apache License 2.0
7.31k stars 318 forks source link

Review Behavior When Replacing Variable Names with Parameters Names in Nodes #7465

Closed jdunkerley closed 4 months ago

jdunkerley commented 11 months ago

When connecting a node is connected to a function it is shown as the parameter name.

image

This includes switching the left input to self. If the function is not identified then it is shown as the variable name of the incoming.

https://github.com/enso-org/enso/assets/4699705/785f5bf4-9eb5-4e79-9ae8-20c9fa8ec880

If then resolves then it changes to the new name.

It the design self should not be shown for methods. We need to agree the design for operators.

We need to review what it should look like when connecting to a parameter spot. The current behavior of still showing the parameter name is useful, replace within just a link would be less clear.

As it stands, both of these designs hide the actual code.

wdanilo commented 11 months ago

Regarding regular functions, in the design, the self input is not visible, instead, it is an arrow pointing to the node:

image

Regarding operators, we might want to keep self visible, but maybe we don't want to. This is a good question. On one hand, operators are easier to read this way, on the other hand, seeing self as an arrow indicates more clearly that the operator is overloaded by the self type. This needs to be discussed further. I feel that keeping self as a port here is a better solution.


Regarding names on ports – showing the names of arguments instead of names of connected variables is IMO a good decision, as it allows the user to understand what the node is about. Seeing a node union <tables> is way more readable than union <operator2>. I don't think we should show the variable name instead of argument name ever, even if the operator is not resolved – this is not consistent and confusing. If we do it (as in the video posted in the first post of this thread), then sometimes we are showing variable name, sometimes argument name, and user does not know when we show what. In my opinion, it would be much better to either show argument name (after function resolution) or just an empty space (with maybe 3 dots) indicating that connection is there, but function is not resolved yet.


Regarding the point that this representation is not a code, the answer little bit more complex. We can see code in code editors in many different ways. For example, in IntelliJ, there are options to in-line show argument names or to hide them. These options allow the users to easier understand the code. I want to emphasize here, however, that Enso is not a code editor. It allows to edit the code, but with big focus on no-coders experience. If we have a code v2 = v1.foo bar=2, what we see on the node is foo <bar> with a connection going from bar to another node. The connection indicates clearly what variable is used in the argument's place. Nodes should have visible names (and this is a missing part in the new design that I totally forgot to add before leaving for vacation). So if you see foo <bar>, you can see where <bar> is connected to, to get the name of the variable. This graph representation is not hiding the code, it is just showing it using one of many isomorphic transformations. Yes, our graph is not a code. Nodes are connected with edges, instead of forming lines of continuous text. I don't think that showing everything that is in the code on nodes would be a good decision. However, we should keep it as close to code as possible, allowing users to type the code by looking at other nodes. The current design shows nodes and connections and describes to what arguments the connection goes to. I believe this is the best option of all that we considered, as it allows the nodes to be short, very readable, and allow people to read them as a code. The only thing that is missing is the part after = (v2 = v1.foo bar=...), which is easily findable by traversing the edge connected to that argument.

Said that, I think it would be a very cool option to have a shortcut (and an icon) to expand the port names to full code. I am not sure if this should be applied to all nodes, only the selected one, or maybe only to the port that we are hovering. For example. However, I am not sure if this would really be needed and I am not sure if any user would ever use it. Still, it is worth considering in the future IMO.

farmaazon commented 4 months ago

New design addressed in new GUI, closing.