How to improve Visualization Previews

[farmaazon]

So, the Component Browser's Visualization Preview was implemented some time ago, and roughly works as described in the design. But once the CB was used by various people, a few UX issues emerged:

1. According to the design, the preview shows the result of applying the currently selected entry, not the input itself. That seems to be very confusing for the users: I've received at least two reports about "not working visualization preview".

2. To show the preview, the Component Browser just updates the node's expression in the engine. This has an effect of propagation to the next nodes if we edit an existing node. It may be considered a useful feature, but it also can confuse users, especially when the preview has an error - it's immediately propagated through the graph, giving an impression of some corruption. And preview errors are very common when editing an existing node, as the first selected entry usually returns a wrong type.

3. The considerations on point 2 has impact on the implementation of "Write-Data Execution Control" : The design says so far about blocking writing for the previewed node, but with current implementation we need to block writes entirely, as the preview has an influence over next nodes in graph (where some of them may be storing data to file or database).

Any thoughts on this?

[wdanilo]

Good points. Let me cover them from my perspective:

1. I agree that currently it is confusing. IMO this will be solved by 2 things:
   a. When typing, a gry-oud text should be displayed in the input text to show what is the real thing that is inserted there.
   b. When the best match scoring is really low, the component browser selection should disappear and we should accept what is written, as is.

2. Very good point. I'm not sure though if our behavior is correct or not from the UX perspective. I see valid cases where while editing a node I want to see how it affects rest of the graph and I see valid cases where I do not want it. We need to chat more about it.

3. What part of the design you are referring to? Are you referring to the part that tells that some functions will be marked to not show results until the user accepts what's written in the node? In such a case we can simply not update the code until enter is pressed, right?

[farmaazon]

Ad 3: If we do not update code at all, then the visualization previews won't work at all. At least the current implementation.
Not-updating-code only when user selects "marked" function does not work, because we can edit node which result is saved to file in another node, so even choosing a "normal" node (e.g. map) will propagate results to the "File.write" node.

If the visualization previews would not propagate, we don't have this problem

[farmaazon]

Ad 2. There is also a problem reported in #6049 - if we want to hide errors on visualization preview, then we should probably hide it from other nodes as well. We cannot just not update code if it gives an error, because we need to run it to know it gives an error.

[wdanilo]

Ok, let's have a brainstorming call about it when Sylwia will be back. Will next Monday work for you?

[farmaazon]

Every free time in my calendar and during working hours is good for me.

[sylwiabr]

I would like to get back to this topic as it is hitting us more and more. @farmaazon @wdanilo let's talk as soon as possible.

[hubertp]

I think #6734 is an example of the kind of problems visualization preview has.

[farmaazon]

The issue was merged with #6486, and I put the higher priority on it.

[farmaazon]

Created an issue #7152 which, along with latest changes in Component Browser (not selecting entries by default), should resolve problems described in the original post.