Constrained Integration Area UX

[kahboom]

At the moment, the visualization area can be divided into two sections: the integration itself and the canvas it sits on. Users can drag and drop steps onto the canvas or onto the integration (a non-draggable, "constrained" part of the canvas). If dropped onto the integration and there is an existing step, it will be replaced with the new step. If dropped onto the canvas, that step is considered a "temporary" step and is not part of the YAML file. In other words, it's not part of the "source of truth" and will not be synchronized.

We would like to make this distinction more apparent to users, and the goal of this discussion is to determine the best way to do that. As an aside, we can also consider how useful it is for users to be able to drag and drop steps onto the canvas temporarily. The original idea behind it was to allow them to configure the step or plan the integration, before adding it and having it change the YAML.

Considerations & Points of Discussion

1. Usefulness of allowing users to drag and drop a step onto the canvas, where it will not be synchronized with the YAML.
2. Intuitiveness of designs--will it be obvious to the user that one area is constrained and syncs with the YAML, and the rest of the canvas will not?

Ideas

Grid Canvas

Add a canvas background to show that this is a workspace area. The solid background behind the integration shows it is the official integration that gets synchronized.

[brunoNetId]

About 1)
I find the idea similar to when working on pure code, the developer wants to try different lines of code, and comment/uncomment portions of code to activate/deactivate them for iterative trial and error.
Other than that... why would you want to have a non-participating action if it doesn't end up connected? And if it does... why not connect it in the first place?
This also makes me think about the following... when working with code, comments are allowed, and it is actually good to document the code to allow others to understand it. Maybe that is an idea to consider... or an idea that would back this concept of working on the grid.

About 2)
I think it's not problematic. At first, the user might be a bit confused, but once familiarised it should be fine.
However, I tend to think this concept adds a complexity that I don't find of priority. It looks nice, but considering the work ahead I would lower its priority and focus on higher priority tasks first. I think this also applies to the concept of 'commented code'

[kahboom]

Thanks for this, lots of great points. So, the constrained area vs canvas temporary steps is already implemented, so it would just be a matter of adding the grid background (quick to do) and knowing if it is enough for users to understand. Of course, the discussion also opens up the question of whether or not we should have the temporary steps to begin with (we could easily undo this should users not find it helpful).