Andarist
commented
2 years ago Thank you for the feedback! When I was implementing this feature I was actually debating how this should be moved. I've found out that different software actually handles this differently (for example our behavior matches the one that can be found in Whimsical and some others).
I see your overall point and maybe we should revisit this. I've just tested out again a bunch of application and it seems that I personally don't care about this at all as I just adjust myself to the given behavior without thinking about it that much. I can see how it could be different for other people though.
I don't think though that there is an obvious single answer here. I find some of the given examples (like Excel or VS Code) to be a stretch here. While the end result is, in fact, that the arrow keys move the viewport - I don't think this is their goal and why they behave like this. In those types of software, the cursor is being moved in the given direction and the viewport is simply being moved in to avoid losing the track of that cursor, for it to stay in the viewport. So while the end result is the same, the goal is different (OTOH one could argue that it doesn't quite matter as people intuitively could absorb this end goal to be a de facto standard of how things work).
I feel like the whole debate about the viewport is a little bit misguiding here. I strongly feel like this is the implementation detail - we think about it because we are software developers, we know how this is usually implemented and we see it as a pattern spanning a lot of applications. However, the most important thing to discuss here is the user experience. An average user won't ever think about viewports (although they might notice the difference if they are already accustomed to a different behavior from another software). The question here is if by pressing an arrow key the user wants to move the graph to the given direction (interaction type that we can find in many games) or if they want to reveal a part of the screen in that direction (interaction type known from canvas-like apps, but not all of them).
Description
The keyboard arrow shortcuts (when used in the VS Code extension) do the opposite of what I would expect. I cannot find a bug referencing this, but I assume it's been discussed before. As a new user, I find the current implementation confusing.
Expected Result
I expected the arrows to simulate moving the viewport in the direction of the arrow by moving the drawing space in opposite direction. I expected the up arrow, for example, to move the view up to a higher part of the drawing (i.e. move the content down); the right arrow to move the view to the right (content move left), etc.
This is how all applications I commonly use work, so a brain-flip is needed when using the arrow keys in the XState Editor. Some examples: VS Code, Excel, Final Cut Pro (really, anything with a cursor) Miro, probably others.
If in the future the XState Editor will use arrow keys to move a selected object within the drawing, this change would be even more important. I would expect the object to move in the arrow direction, and if it encounters a viewer border I would expect the viewport to appear move in that same arrow direction to keep the object visible, meaning the drawing space would move in the opposite direction, as I am suggesting would also be the expected behavior without an object selected.
Actual Result
The four arrows moved the viewport in the opposite direction of what I expected.
Additional context
Using the XState VSCode 1.9.2 in VS Code 1.70.0 on a Mac.