Feature Summary
Texera ships 166 operators across 26 groups, and there are three moments where
the editor gives a user less help than the metadata it already has could:
-
Finding an operator. The palette search matches the query against
userFriendlyName only. A query phrased as an intent — "remove repeated
rows" — matches no name, so it returns nothing, even though Distinct's own
description says exactly that. Every operator carries an
operatorDescription; the search never reads it. In practice the search only
helps someone who already knows the operator's name.
-
Reading a workflow. Once an operator is on the canvas it shows a name and
nothing else, and a renamed one does not even show that. Understanding
someone else's workflow means clicking each operator to open its properties.
-
Knowing what comes next. With a workflow half-built, there is no hint of
what usually follows the selected operator; the user goes back to the search.
Proposed Solution or Design
Three independent, frontend-only changes, each as its own PR so they can be
reviewed and accepted separately. None touches the backend.
A. Context on hover. Hovering an operator on the canvas shows its group and
description plus its neighbours in the current workflow (what feeds it and what
it feeds). The description is existing metadata; the connections are read from
the workflow graph, so nothing is inferred. The card follows graph changes while
open. It stays out of the way while the heat-map overlay owns the hover.
B. Semantic operator search. The palette search also ranks operators by
meaning, in the same box, with no mode to choose. Keyword matches still render
first and instantly, so typing a name behaves exactly as today; ranked matches
fill in underneath. Operator vectors are computed offline and committed as a
~490 KB asset; at runtime only the query is embedded, in the browser, with
all-MiniLM-L6-v2 through Transformers.js. No backend, no API key.
Measured on 166 queries — one per operator, written from the operator catalogue
without seeing the index — the current search returns the expected operator in
the top three for 2 of them; the combined search does for 137.
C. Next-operator suggestions. Selecting an operator shows what usually
follows it; choosing a suggestion places it next to the selected operator and
wires the two. Suggestions come from a small rule table keyed by operator group,
ordered by the links in Texera's own example workflows.
This came out of the UP Hackathon (September 2026), where these were presented
to Chen Li. We would like to confirm the direction before the PRs are
reviewed, and are especially interested in feedback on B's runtime model
download (see the PR for the options).
Affected Area
Workflow UI
Feature Summary
Texera ships 166 operators across 26 groups, and there are three moments where
the editor gives a user less help than the metadata it already has could:
Finding an operator. The palette search matches the query against
userFriendlyNameonly. A query phrased as an intent — "remove repeatedrows" — matches no name, so it returns nothing, even though
Distinct's owndescription says exactly that. Every operator carries an
operatorDescription; the search never reads it. In practice the search onlyhelps someone who already knows the operator's name.
Reading a workflow. Once an operator is on the canvas it shows a name and
nothing else, and a renamed one does not even show that. Understanding
someone else's workflow means clicking each operator to open its properties.
Knowing what comes next. With a workflow half-built, there is no hint of
what usually follows the selected operator; the user goes back to the search.
Proposed Solution or Design
Three independent, frontend-only changes, each as its own PR so they can be
reviewed and accepted separately. None touches the backend.
A. Context on hover. Hovering an operator on the canvas shows its group and
description plus its neighbours in the current workflow (what feeds it and what
it feeds). The description is existing metadata; the connections are read from
the workflow graph, so nothing is inferred. The card follows graph changes while
open. It stays out of the way while the heat-map overlay owns the hover.
B. Semantic operator search. The palette search also ranks operators by
meaning, in the same box, with no mode to choose. Keyword matches still render
first and instantly, so typing a name behaves exactly as today; ranked matches
fill in underneath. Operator vectors are computed offline and committed as a
~490 KB asset; at runtime only the query is embedded, in the browser, with
all-MiniLM-L6-v2through Transformers.js. No backend, no API key.Measured on 166 queries — one per operator, written from the operator catalogue
without seeing the index — the current search returns the expected operator in
the top three for 2 of them; the combined search does for 137.
C. Next-operator suggestions. Selecting an operator shows what usually
follows it; choosing a suggestion places it next to the selected operator and
wires the two. Suggestions come from a small rule table keyed by operator group,
ordered by the links in Texera's own example workflows.
This came out of the UP Hackathon (September 2026), where these were presented
to Chen Li. We would like to confirm the direction before the PRs are
reviewed, and are especially interested in feedback on B's runtime model
download (see the PR for the options).
Affected Area
Workflow UI