[Bug]: Interactive graph UI does not follow standard interaction patterns and is difficult to use

[thanhminhmr]

Apache Hop version?

2.17.0

Java version?

Java 21.0.8 (Eclipse Adoptium)

Operating system

Windows

What happened?

(This bug report is written with the aid of AI writing tools to be more professional and to filter bad words from the original reports from my team.)

The interactive graph element in the Apache Hop GUI behaves in a way that does not follow common UI/UX conventions for interactive graphs. As a result, interacting with the graph is confusing and often feels like fighting the interface rather than using the tool effectively.

The current interaction model appears inconsistent with common interaction patterns used in graph visualization tools and modern UI frameworks.

Observed Behavior

1. Single-click behavior

   • A single click on graph elements immediately opens the Action GUI for that element.

   • This happens even when the user likely intends to:

     • inspect the graph
     • select an element
     • interact with the visualization

2. No right-click context menu

   • Right-clicking on the graph does not bring up a context menu.
   • Context menus are typically the standard way to expose element actions in graphical tools.

3. Unexpected interaction model

   • Basic exploration of the graph becomes difficult because most clicks trigger configuration dialogs.
   • The interface interrupts exploration workflows.

Overall, using the graph currently feels like fighting the GUI rather than using it to accomplish a task.

Expected Behavior

The graph interaction should follow common UI patterns used in interactive visualization tools:

Typical expectations include:

• Left click: Select or highlight a graph element
• Double click: Open configuration or action dialog
• Right click: Show context menu with actions
• Drag: Move or pan the graph (if applicable)

These patterns are consistent with many applications such as:

• IDE graph views
• workflow editors
• diagram tools
• visualization libraries

Following these conventions would make the interface significantly more intuitive.

Impact

The current behavior negatively affects usability because:

• Simple exploration of the graph is interrupted by dialogs
• Users cannot rely on established interaction conventions
• It increases friction during normal workflow navigation

This may particularly impact new users who expect standard graph interaction patterns.

Suggested Improvement

Adopt more conventional interaction patterns, for example:

• Use single-click for selection
• Use double-click to open the Action GUI
• Provide right-click context menus for actions
• Avoid triggering configuration dialogs during exploratory clicks

This would align the interface with common UX expectations for interactive graph tools.

Additional Notes

The issue appears to be related primarily to interaction design rather than functionality, but it significantly affects usability of the graph interface.

Issue Priority

Priority: 2

Issue Component

Component: Hop Gui

[bamaer]

It sounds like enabling the "Use double click on canvas" option (Configuration perspective -> Look & Feel) would solve a lot of your problems.

[thanhminhmr]

Yeah, I actually pointed that option out to the team about a week ago. It does help a bit, but people still seem pretty unhappy with the single-click Action GUI behavior and similar interactions.

It also doesn’t feel like a "new tool resistance" thing. They’re genuinely trying to use it. But watching them, it’s pretty clear they spend a lot of time fighting the GUI instead of getting work done.

For example, connecting two transforms: you have to hold Shift, click the first, then click the second, then pick the hop type from a context menu that only shows up after the second click. I’ve seen people accidentally close that menu a lot.

Another example: people click on a transform expecting to just select or interact with it, but instead it opens the Action GUI. From there, they sometimes misclick something unintentionally, which disrupts their flow.

So even with the double-click option, the interaction model still feels pretty unintuitive in practice.

[hansva]

For connecting Hops we tried to add as many possibilities as possible. You can:

• Shift-click, and then click on the second transform (I do not recommend this one)
• shift drag, and release the mouse on the second transform
• middle mouse button click or drag
• click on a transform and press the create a hop

Can things be improved? Probably, I am not of the clicking type, and I noticed the context menu pops up when you are in hop creation mode, which seems like a bug (which hasn't been reported before, as far as I know).

Options could be created for all these asks, making the tool more configurable to your personal needs.
I would create separate feature requests:

• Add an option to move the context dialog to the right click

That's an actionable ask, and if one of the community developers wants to pick it up, it will be done in one of the future releases.

[thanhminhmr]

Thanks, that’s helpful. I think the issue isn’t really the number of ways to do things, but that the default interactions don’t match what people expect. Most users won’t discover alternatives—they just try what feels natural.

From what I’ve seen, people struggle before they even get to those options.

A simple improvement might be to allow mouse button rebinding:

• move Action GUI to right-click
• use left-click for selection

That alone would probably prevent most accidental clicks and make things feel much more intuitive.

[sklaffke]

I can only agree what @thanhminhmr is proposing, the actual UI handling isn't efficient in my opinion. Simple actions like delete, preview have to be searched in this pop-up dialog which is overloaded with too many actions. On the other hand in the file explorer view you can use right mouse for any actions (Git add, etc.) - not a consistent behavior. Additionally, it would be helpful to have all transforms in a view on the left and have split views on the left (like in VS code), either to choose a file (top left view) or to search and select a transform (bottom left.

[hansva]

It can all be solved, with options to customise the UI to your personal preferences. And some of these features have active development. 2.18 will introduce a Split View. It all boils down to development time and things that personally annoy people working on the code.