wierkstudio/ciphereditor

Initial observations

Jordy3D opened this issue · 0 comments

Before I start, I am glad to see Cryptii evolving, and into a node-based editor no less.

That said, here is some observations from playing around with the current at the time version of ciphereditor:
General:

  1. Nodes seem to have the option to get input from and output to variables, however actually knowing where those variables are coming from is not clear unless you've directly created them and noted the name of them. Having a list of these variables available somewhere would make things easier, especially if that list updates the values with the Graph, and if clicking on those variables took us to or highlighted the place they originate from. Alternatively, or in combination, having the variable name appear as a label next to the Node output could also help.
  2. The blue button that brings up the Description of a node feels a little unnecessary. The Up/Down arrow on the button implies that it will shift things in reverse or something, but it only seems to bring up a Description box. If that's all it's intended to do, then I believe having the name of the node at the top of the Node would be nicer overall, and more clear as to what each node is doing. This could also go a long way in making Nodes easier to click without making something shrink or expand, which just feels kinda clunky.
  3. The right-hand sidebar feels rather large when open, but the button to hide it also makes things feel odd to me. Perhaps having that button still be there, but supplemented by a bar on the edge of the side menu allowing manual resizing could help bridge that?
  4. Zooming. I know you mention using the built-in Zoom functionality of the browser, but that's less than ideal in a number of situations. A dedicated ability to zoom, either with a scroll or with +/- buttons on the UI, would not go unappreciated.
  5. Node input/output path collision. This is definitely less of an important thing than others, but it's still worth mentioning, if a Node is placed on top of a path between inputs/outputs, the path ignores it and continues as if it wasn't there. This could make more complex nodes a little less manageable. A tried to use Empty Control nodes as a sort of "relay" node, but that didn't seem to work as I expected.
  6. When two Paths overlap each other, it can be confusing where data is actually going to/coming from. I know there's a dark outline around them that helps a little, but separating the two lines when they overlap may come in handy in certain situations.
  7. Drag-to-Remove Paths. This is a feature I rather enjoy in some other node-based editors. It's not initially clear that you can click on a Path and then press Delete to remove it. I guess that could just come down to a future tutorial of sorts on how to use ciphereditor
  8. While testing further, I seem to have accidentally had the sidebar display button disappear. I am not sure what caused this, but I had to refresh the page for it to return.
  9. A dedicated right-click menu could also be nice. More so if it was similar to ones like Amplify Shader Editor for Unity, where you can right-click and start typing to quickly find desired nodes. Not so important now, but as more nodes and features get added... It may help in the long-term.

Specific Nodes:

  1. On the Binary/Text encoding node, it seems rather unclear on how to flip the operation around (from text to binary, instead of the default binary to text). The "Alphabet" name for the setting in that Node doesn't really feel like it conveys a sort of "encoding mode" of sorts.
  2. On the Word Counter node, the Character Count, Word Count and Line Count values seem somewhat inconsistent in the way they can be used. I assume this is down to the Type of the value.
  3. The Case Transform Node has (and I assume others have) the ability to output their mode of sorts as a string for use in other nodes. However, the string they output does not match with the string we see in their relevant dropdown menu, instead using camelCase strings or other raw values. This alone is fine, but perhaps a preview of what it would output could be handy.
  4. The OR, NOT and AND Nodes may be benefited by allowing other nodes to enter them (other than the other logical operator nodes). For example, if a Word Counter node's input results in an output of Word Count 1, that should be readable by the logical nodes. This could also work in tandem with:
  5. A Switch/IF node. Changing the output path of data based on incoming conditions, such as "value greater than" or "string contains" or what have you can lead to deeper interactions between the nodes and more freedom overall.

I hope this didn't come across as too nit-picky or something!
I just really like node-based editors, and this would be a great application to see thrive going forward.