Pinitsdv opened a new issue, #8627:
URL: https://github.com/apache/texera/issues/8627
### 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:
1. **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.
2. **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.
3. **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
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
