Making Texera easier for researchers to get started with

[eugenegujing]

Hi all, I've been thinking about Texera's usability for a while and wanted to open a discussion before filing issues.

The problem

The platform has become more powerful than ever, but for a first-time researcher it has also become harder to get started with. A new user in an empty workspace is already looking at around 55 buttons, panels and tabs before touching a single operator, and the operator menu has 165 operators (64 ML, 50 visualization). A lot of what's on screen is infrastructure rather than research, for example the warehouse and Python environment options. These are all useful, but for a researcher who just wants to get an analysis going, figuring out what they are and whether they matter can take a lot of time and energy.

I think while we keep adding features, we also need to subtract on the UI and experience side, so a researcher can get to what they actually want to do without getting blocked by things that are obscure to them. This doesn't mean removing anything. It means changing what shows up by default and how the platform explains itself.

A few directions

These are rough ideas, roughly in order of cost. I'd like to hear which ones people think are worth pursuing before writing anything more detailed.

1. Make the operator menu teach instead of just list.
Search over operator descriptions, not only names, so "remove duplicates" finds Distinct. Hover cards with a one-line explanation and an example, pulled from the operator reference pages being generated in #9031. "Typically next" suggestions based on what's selected on the canvas, computed from how operators are actually chained in existing workflows. And separately, a lot of the advanced features could be hidden by default and turned on or off by the user later once they need them, similar to what #6102 did for the computing unit modal.

2. Hands-on onboarding.
Instead of a "Next, Next, Next" overlay tour, a short guided flow inside the real workspace on a sample workflow: change one operator, run it, see the result, with each step advancing when the user actually does it. This would largely follow what #5104 prototyped (credit to @xuang7 for the idea), plus #9151 for the tutorial workflow that new users get.

3. A platform-wide AI assistant.
Grow the current workspace agent into one assistant reachable from anywhere. First just grounded Q&A about Texera's own features and docs, later dashboard actions like uploading a dataset or cloning a workflow, with confirmation, reusing the existing REST endpoints as the agent's tools.

What I'm asking

• Does this direction make sense for the project?
• Any suggestions on these ideas, or better ideas for reaching the same goal?

Feedback and any other ideas are welcome.

[xuang7]

I agree that Texera could be more approachable for new users. We have lots of powerful features, but from a user's perspective, they may not always be easy to discover or know how to use. We have some helpful tutorial videos, and there's ongoing work on operator-level documentation, including docs and short demo videos.

In addition to operator-specific references, I think task-based tutorials could also be helpful. For example, we could organize tutorials around common tasks, such as cleaning datasets, transforming data, or creating visualizations. Interactive, step-by-step tutorials could be another good direction. Providing pre-built tutorial workflows that new users can open and follow, with guided instructions as they configure operators and run the workflows, could be very helpful.

More user-friendly error messages would also be valuable, as some of the current error messages may be more geared toward developers. A well-trained AI agent that helps users navigate Texera and understand its features also sounds like a good idea. Beyond answering questions, it could assist with troubleshooting by explaining errors in a more beginner-friendly way and suggesting possible fixes based on the workflow context. This could be especially helpful for users who may not be familiar with the technical details behind error messages.

[chenlica]

@eugenegujing @xuang7 these are all good ideas.

1. We can support semantic search on the operators. @carloea2 I remember there was a related effort in a recent hackathon. Do you remember?

2. We need to gradually develop more video tutorials for new users to watch. Training sessions are also needed.

3. A more powerful agent will definitely address some of these concerns.

@eugenegujing You are welcome to propose concrete features to improve the system.

@zyratlo Do you want to chime in based on your recent interactions with domain users?

[CaroFernando]

I was also a relatively new user recently, and I had a very similar experience. I agree that making Texera more approachable for new users is worth exploring. Semantic search for operators sounds like a particularly good idea, as it could make discovering the right operators much easier for users who are not yet familiar with the available operators.

Regarding the AI agent, I think there is a lot of potential for further development. Since there are already various ideas and ongoing efforts in this area, it might be useful to have a separate discussion to centralize these ideas in one place, discuss possible directions, and reach a shared agreement on priorities and next steps.

[zyratlo]

I've spent the last couple of months helping a biology researcher on dkNET, so this comes from that.

Our development process was like this: they would tell me what analysis they needed migrated to dkNET, I would make it, and then they would use it and give me feedback for what they want changed. They never built a workflow from scratch, they ran one that I prepared for them. So from their use case, all they do is find the workflow I shared, upload a gene list, select it in the workflow, run, look at the results and export. This is a related but slightly different user experience than a domain researcher who creates their workflows from scratch.

A lot of the questions they asked were related to using the platform instead of developing a workflow. Here are a few problems they ran into to give you an idea of where they got stuck:

• The shared workflow wasn't where they looked. They opened the Hub instead of "Your Work".
• After picking their dataset, the Select button stayed grayed out until they clicked the file name inside it.
• It's possible to create a dataset with no file in it. They did this while testing and got a run with no results and no explanation.
• After running, they saw a row count but didn't know where the results were, and the result panel didn't open on its own.
• Export failed once because an input dataset wasn't marked downloadable, and another time it just did nothing until they cleared their browser cache.

The technical jargon was a barrier as well, not only the number of buttons. When they reviewed my tutorial guide (for context, a guide I am writing to help new users get started and clone a workflow, upload a dataset, and run an analysis), they flagged "cloning", "operator", "version control", "computing unit" and "execution" as things that could put people off, so I rewrote it without them. I don't think we should completely remove technical words since users still have to learn some of them, but it is something we do need to keep in mind.

Hiding advanced options by default like in point 1 helps with not overwhelming the user, and #9151 from point 2 would also have saved them a step in the tutorial.

+1 to @xuang7 on error messages. The worst moments were silent ones, like an empty result with nothing saying why. They asked a lot of questions about when something went wrong without an explanation of why (like no error message, or a wrong result). To help with this, in our workflow I changed the analysis to stop with a message saying what to fix in the gene list.

Most of their questions were "how do I do X in the UI", and even with a guide they sometimes asked something it already covered, because the answer wasn't on screen when they needed it. The YouTube videos help, but they mean leaving the platform. So I'd support the in-workspace onboarding in point 2 and the assistant in point 3, and it would be even better if they also cover datasets, running, and results, not just building a workflow.

The result panel was where they spent most of their time, and their feedback on it is in #9123.

[chenlica]

A few things we can do to solve these problems:

• Develop more documentation, tutorials, and videos;
• Make the agent more powerful.

[eugenegujing]

Thanks everyone for the input.

Reading the replies, the common thread is the agent. Most of the questions a new user hits, from "why did my run fail" to "how do I do X in the UI", are ones an agent could answer on the spot, but the current one cannot. It does not see the errors from the user's own run, it cannot read Texera's documentation, and it does not know which datasets the user has. So I think making the agent more capable is the most necessary next step, and it needs more implementation work than discussion.

As @CaroFernando suggested, I opened a separate discussion to keep my agent ideas in one place. It has three concrete proposals, see #9377. I will open issues and draft PRs there for each change so the work can be tracked. Feedback on the proposals is welcome.