Unified Run and Deploy Button

[dominiklohmann]

Currently in the Explorer, users must decide whether they want to Run or Deploy a pipeline. However, at most one of the two actions makes sense at any given time, given that Run requires a void to events and Deploy a void to void pipeline.

We want to unify the two buttons into a single Run button, and move the logic for deciding which action to take into Tenzir itself.

### Definition of Done
- [x] Design UX of the button for a pipeline that can be run or deployed, respectively.
- [x] Implement changes in Tenzir.
- [x] Adapt to new API in the Explorer.

[jachris]

An alternative design to consider is that we could also provide an endpoint that parses a pipeline, returns diagnostics if necessary, and gives information about the possible input and output types. This would mean that running a pipeline incurs an additional network call (deploying stays at 2), but gives a bit more flexibility as we don't have to take the entire logic into Tenzir itself. Also, we could provide diagnostics while typing (although functionality like this was met with internal opposition previously).

However, one more thing, because this is issue more or less about reimagining the API: For diagnostics, we need to pass the editor contents separate from any explorer-generated sinks (or explorer-generated sources, once we have file upload capabilities). In any case, the new API should also accommodate this.

[tobim]

I'm a bit concerned about the loss of discoverability of a feature - namely creating new managed pipelines - that is core to the user value.

I do agree that the deploy button in it's current form is sub-optimal, but at least it is a visible interactive element that somehow signals to the user "here is the place to connect thing together".

Without going too much into the solution space, I think as a user I would appreciate a top-level entry point that handholds me through the process of deploying a managed pipeline. For example some kind of wizard that lets me choose source, sink and transformation. instead of creating a managed pipeline directly the "deploy" button would send the the user to the same wizard but with the source and transformation filled in from the editor contents.

[mavam]

What you describe sounds like an entirely new roadmap item, e.g., "Pipeline Wizard". I see that complementary to this issue. What you describe very much resembles the "visual operator picker" that I sketched out in an early Excalidraw. Basically compose your pipeline with a few clicks, instead of writing one in TQL.

Solution space idea to get closer to the desired effect within the scope of this story: in order to make the deploy scenario a bit more distinctive, we could change the color of the button once a sink is present.

[jachris]

Solution space idea to get closer to the desired effect within the scope of this story: in order to make the deploy scenario a bit more distinctive, we could change the color of the button once a sink is present.

Such functionality was met with opposition before (mainly from @dit7ya), because whether a sink is present can only be decided after we have parsed the pipeline, which requires a call to the backend. Thus, we would have to constantly submit the pipeline to the backend and there would be a delay until the button changes colors.

[mavam]

Such functionality was met with opposition before (mainly from @dit7ya), because whether a sink is present can only be decided after we have parsed the pipeline, which requires a call to the backend. Thus, we would have to constantly submit the pipeline to the backend and there would be a delay until the button changes colors.

If the limitation are only user-defined operators, then we have something that's 90% there and good enough until we have better TQL parsing. I'm not sure what the other reasons were, if any.

[tobim]

Solution space idea to get closer to the desired effect within the scope of this story: in order to make the deploy scenario a bit more distinctive, we could change the color of the button once a sink is present.

I don't think this is enough. My point is that the current proposal reduces the discoverability of the deploy function and that makes the app worse.

[dominiklohmann]

This topic came up again in our Discord, where there was again confusion with the two buttons: https://discord.com/channels/1072605116978442320/1136235026678296737

[mavam]

We (@annadehtiarova, @jachris, @tobim, and me) discussed how to proceed here.

After agreeing that we want to make the UX context-dependent, i.e., a function of the presence of a sink, we explored several pathways:

1. Use a single button that changes its shape based on the presence of
   1. a sink
   2. an error
2. Make the sink more explicit, e.g., by introducing a dedicated line below Editor where Explorer would be one possible sink
3. Use a toggle-like button that flips between the Run and Deploy state. Basically (1) but with words.
4. Offer a toggle to switch between a code (= Editor) and graphical pipeline representation akin to Elixir's Explorer.

We ultimately agreed on (1) as viable path forward and reserved (4) for later exploration. A primary concern was that we did not want to split the pipeline into pieces, but rather treat it as unit in itself—like a piece of code.

A related topic that we need to address in the design is how we want to render errors, i.e., when it's neither possible to run nor to deploy a pipeline. Should we use the results pane? Or just underline the faulty parts in the pipeline with an error on hover?

Finally, @jachris mentioned an evolutionary idea of live-updating the results as the user types, completely ditching the run/play button. We would like to explore this idea in a separate roadmap item.