Modernizing ECC Workflow: Reducing UX Friction and Manual Layout Effort #2169

"Hi @azoitl and the 4diac community,

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

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.

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.

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.

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.

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,

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.