Modernizing ECC Workflow: Reducing UX Friction and Manual Layout Effort

[vikash1703]

@azoitl and the 4diac community,

As part of my preparation for GSoC 2026, I have been analyzing the ECC editor’s current workflow. While working on the coordinate system refactoring (ref: PR #1986 philosophy), I identified three key "Innovation" areas where we can significantly improve engineering productivity by learning from modern tools like Draw.io, Figma, and Unreal Engine Blueprints.

I would like to share the following ideas as possible milestones for GSoC 2026. I would really value your thoughts and suggestions on them:

1. Smart Snapping & Visual Alignment Guides
The Problem: Aligning states is currently a manual "pixel-pushing" task. In large IEC 61499 charts, keeping the layout organized is time-consuming.

The Innovation: Introduce dynamic alignment guides (Visual Snapping). As a user drags a state, temporary lines should appear to help align it perfectly with existing states.

2. Intelligent Transition Routing (Obstacle Avoidance)
The Problem: Moving states often leads to transitions overlapping unrelated objects (the "Spider Web" effect), requiring manual bendpoint adjustments.

The Innovation: Implement basic auto-routing logic so transitions intelligently route themselves around states, maintaining visual clarity automatically.

3. Rapid Connection Logic (Ghost Anchors)
The Problem: The current "Palette-to-Canvas" travel (select tool -> click state A -> drag to state B) is repetitive and slow.

The Innovation: Add Ghost Anchors (hover-sensitive icons) on states. Clicking an anchor should instantly spawn a connected transition/state, enabling a "one-click" design flow.

[azoitl]

@vikash1703 thx for this assessment. point 1 and 2 sound interesting but also very challenging. Especially for 2 we may need to discuss how transitions should be drawn. but I would be curios.

Your point 3 sounds also very interesting. Curios how this would look and feel.

[vikash1703]

"Hi @azoitl and the 4diac community,

I am currently studying the technical implementation for all three ideas and will share a detailed plan soon.

[vikash1703]

Hi Alois,

I’ve been working on the refactoring as you suggested. I've broken it down into the four-stage process: cleaning CreateECStateCommand to be generic and then correcting the positions in TransitionStateCreationTool, ECCXYLayoutEditPolicy, and NewStateAction.

Since this establishes the 'Solid Basis' we talked about, I’d like to have a quick discussion to sync on these changes and also brainstorm which GSoC enhancements would be most impactful to build on top of this foundation. Let me know when you have a moment.

[azoitl]

Hi @vikash1703, I would really have hoped that you would have turned the first step already in an PR. This would help me much better understand what you did and provide support for more focused discussion.

As additional input for your work I had a meeting with one of my students and there a few usability issues of the ECC editor where brought up:

• improve error feedback in ECC (e.g., highlight wrong transition conditions, dead states, ...)
• Jump from error markers to the element in the ECC, when we identify errors we create error markers in the Problems view, for other editors double clicking on the problem brings you to the location of the problem
• improve the routing of transition lines. The currently applied spline has a strange trajectory at the start and end. Also the source and end location calculation will need some improvements. I think this will also be needed for your routing idea
• we have the feature that when you drag a transition and press ctrl while dragging the tool changes into a state and transition creation tool. However this feature gets often stuck or does not work reliably.

[vikash1703]

Hi Alois,

Thanks for the feedback and the usability points.

I’ll start working on the first one — improving error feedback in the ECC (like highlighting wrong transition conditions and dead states). I think that’s a good place to begin.

[azoitl]

thanks for cleaning up the PR. I tested it and it should be fine. Just waiting for the CI build to check. However this PR only modernizes the code it does not yet fix the underlying problem. Which is that we either do not consider zoom (native scaling or diagram zoom) or use the zoom manager. Therefore positions may still be off. So for me the next step would be to fix the the position problem by ensuring that the coordinates are correctly translated into the coordinate system of the ECC diagram. The best is to use a translateToRelative(point) method with eh correct figure.

[sshekhar-04]

Hi @azoitl,

Building on this discussion, I would like to pick up the two usability points that haven't been addressed yet:

1. Improve error feedback in ECC — visually highlighting wrong transition conditions and dead states directly in the editor canvas
2. Jump from error markers to ECC elements — enabling double-click navigation from the Problems view to the exact element in the ECC editor, consistent with how other Eclipse editors handle this

I have been contributing to 4diac IDE through issue #2026 (internationalization) and have a good understanding of the plugin architecture and Eclipse RCP patterns.

I would like to explore these two points as the core of my GSoC 2026 proposal. Could you confirm if these are still open for contribution? I would also love any pointers on where in the codebase the error marker and Problems view integration is currently handled.

Thank you!

[azoitl]

AFAIK currently nobody is working on these issues. We use the Eclipse Platform infrastructure for markers. You can look for gotoMarker() methods in our code base to get examples.

However I also want to point out that this is maybe that these tasks are a bit small for a GSoC project even for a small one. In general the infrastructure for these features is there and the missing thing is to implement the handling in the editors.

[sshekhar-04]

Hi @azoitl,

Thank you for the confirmation and the pointer to gotoMarker() — I have already located the existing implementation in ECCEditor.java and identified the specific improvements needed.

I completely understand the concern about scope. To make this a well-sized GSoC project, I would like to propose expanding it to cover the broader ECC editor usability improvement theme — combining the error visibility work with additional usability fixes.

Here is the expanded scope I am considering:

1. Error feedback and navigation (the two points above)

   • Fix gotoMarker() with URI-based navigation
   • Add validation rules to validateECC() for dead states and wrong transition conditions
   • Visual highlighting on the ECC canvas

2. Additional ECC usability improvements (to add scope)

   • Improve the CTRL+Click transition drag mode that gets stuck
   • Address state placement offset when zoomed or scrolled
   • Reduce interaction steps for common workflows compared to the FB Network Editor

This would combine the error visibility infrastructure work with concrete usability bug fixes — covering both the validation/marker side and the interaction/UX side of the ECC editor.

Does this feel like an appropriately scoped GSoC project to you? And are there any specific areas you would prioritize or add?

Thank you!

[vikash1703]

Hi @azoitl,

Thank you for the confirmation and the pointer to gotoMarker() — I have already located the existing implementation in ECCEditor.java and identified the specific improvements needed.

I completely understand the concern about scope. To make this a well-sized GSoC project, I would like to propose expanding it to cover the broader ECC editor usability improvement theme — combining the error visibility work with additional usability fixes.

Here is the expanded scope I am considering:

1. Error feedback and navigation (the two points above)

   • Fix gotoMarker() with URI-based navigation
   • Add validation rules to validateECC() for dead states and wrong transition conditions
   • Visual highlighting on the ECC canvas

2. Additional ECC usability improvements (to add scope)

   • Improve the CTRL+Click transition drag mode that gets stuck
   • Address state placement offset when zoomed or scrolled
   • Reduce interaction steps for common workflows compared to the FB Network Editor

This would combine the error visibility infrastructure work with concrete usability bug fixes — covering both the validation/marker side and the interaction/UX side of the ECC editor.

Does this feel like an appropriately scoped GSoC project to you? And are there any specific areas you would prioritize or add?

Thank you!

Hi @azoitl and @sshekhar-04,
Just wanted to mention that I have already been actively working on ECC usability improvements for some time. I have had four PRs merged in this area and have also investigated the error feedback gap, spline trajectory issue, and Ctrl-drag stuck problem in detail.
Just sharing for awareness.