Show several operators' results at once: a tab per result, and a preview on hover

[kz930]

In one sentence: the result panel gets a tab along its bottom for each operator that has a result, and hovering an operator on the canvas shows its first rows.

Why

The result panel shows one operator at a time, and only while exactly one is selected. To compare two results you click back and forth on the canvas, and the panel empties whenever the selection does.

What I'm proposing

A tab per result. When a run finishes, the panel opens a tab for each operator the run kept a result for. Clicking an operator switches to its tab, and clicking a tab highlights its operator. A tab closes with ×, and a failed operator's tab has a red dot. An operator with nothing to show opens no tab, so the panel never fills with empty tabs.

A preview on hover. Hovering any operator shows a small card. A table result shows its first 5 rows and 6 columns with the size, and a failed operator shows its error. An operator the run did not keep a result for says how to keep one: turn on its eye icon and run again.

This is the prototype:

Does anyone have thoughts on this design, or a different way you'd want to see several results?

[chenlica]

I like the idea of allowing the user to see the results of multiple operators. A main question is how.

Instead of showing them in multiple tabs in the same result panel, it may be more intuitive to show the results of an operator next to the operator. One way to do so is the following: whenever the user hovers the mouse over an operator, a result window will automatically pop out. By default when the mouse leaves the operator, the window will disappear. The user can also "pin" the window so that it doesn't disappear when the mouse leaves the operator.

[zyratlo]

I agree we need some way to see more than one result at a time.

For the auto-popup, I think the hover should stay small and a bit delayed. If it only appears after the cursor rests on the operator for about half a second, and never while dragging, linking, or right after a click, the people who want a peek get one and everyone else doesn't notice it. I don't think it should show the entire result, only a preview. The hover screenshot in the prototype is a good example.

I like the pinning idea, the popup could have a pin button that turns it into a window next to the operator with the full result, so opening a bigger view is always a choice the user makes. A setting to turn hover previews off would be cheap to add too.

I also like the result panel with multiple tabs, my concern is how we'd show multiple results at the same time. Tabs still only show one full result at once, so we'd need either a side-by-side view in the result panel or pinned popup windows. I prefer the popup windows, since the result sits next to the operator it came from, but the extra clutter from windows might cover up other operators which makes the workflow more messy.

[aglinxinyuan]

I like the tab idea, but I’m not a fan of the auto-popup or pinning options. Space on the canvas is already limited—even our current single result panel doesn’t have enough room to display everything.

[sshiv012]

I like the hover result preview direction because it better matches the primary workflow-authoring task. Most result inspection during workflow construction is lightweight: checking row count, schema, or a handful of values, so opening a large bottom result panel introduces unnecessary context switching.
A useful interaction model would be progressive disclosure: hover for a lightweight preview, click/pin for persistent inspection, and open the full result panel for deeper exploration. This preserves the current full result viewer for statistics, column navigation, search, etc., while making the common debugging path much faster. would avoid making the feature purely hover-dependent, though.
There should be a small hover delay to avoid accidental activation, keyboard/focus support, and an explicit affordance or click action to pin/open the result. W3C's guidance for hover-triggered content similarly emphasizes that such content must remain interactable and should not disappear unexpectedly.
Conceptually:
Canvas → Hover preview → Persistent/full result
rather than having every intermediate inspection immediately open the large result panel.

[yangzhang75]

I like both approaches, and I agree there’s room for more flexibility.

On the tabs: Tabs are useful for switching between results, but a single tabbed panel still only shows one result at a time. It would be nice to detach a tab into its own window, so users can view multiple results side by side and compare them directly.

On the hover previews: I have two concerns:

1. The hover cards should be consistent in size and format across operators, so users know what to expect and the layout doesn’t shift between previews.
2. In large workflows with many operators, hover previews may add more visual noise than value, especially when users mainly care about the final result. It would help to let users enable or disable hover previews per workflow or globally.

Overall, I think a more flexible, composable approach would work better: users should be able to choose how they inspect results based on the workflow and the task.

[eugenegujing]

I prefer tabs, and I think they could work like browser tabs. Clicking an operator opens its result as a tab at the bottom of the panel (or switches to it if it's already open), the tab stays until you close it, and selecting a tab highlights its operator on the canvas. This stays close to how the panel works today, where you click an operator to see its result, except the result no longer goes away when you click somewhere else. The tab bar then only holds the results the user actually opened, rather than one tab for every kept result after each run.

To keep tabs from piling up while someone clicks around to edit operators, a single click could open a preview tab that the next click replaces (like VS Code), and the tab becomes permanent once you double-click the operator or interact with the tab. That way a quick look doesn't leave anything behind either.

For comparing results, I'd add a split view on top of the tabs, like Chrome's split view or VS Code's split editor. Dragging a tab to one side of the panel shows the two results side by side, with both operators highlighted on the canvas. The panel still shows one full-width result by default, so the split only takes space when someone asks for it. This could come as a follow-up once tabs are in, and later it could go up to three or more tabs side by side in one panel, to follow the data through three or more steps of a workflow.

I'm not in favor of hover previews. A hover isn't faster than a click, since moving the pointer to the operator takes the same time either way, and a hover then needs a delay (about 0.5s, as suggested above) so it doesn't fire during dragging or linking. The preview also disappears once the pointer leaves, so keeping it for comparison means pinning it. Pinning is still a click, just with more steps in front of it. You hover over the operator, wait for the card, move to the pin button, and then click. Clicking the operator gets you there in one step. Hover only saves anything for a quick look, and clicking the operator covers that too. Hover also doesn't work on touchscreens.