Tuesday, October 22, 2013

Eclipse Diagram Editors From A User's Perspective

I believe that the Eclipse's diagram editing frameworks have a lot to catch up when it comes to usability. For illustration I've created a screencast on how a typical Eclipse graphical editor appears to a user. I have used the Ecore Tools editor as an example, but most issues presented are caused by defaults of GMF or GEF which are pretty hard to change. So don't be surprised if you re-encounter these or similar issues in Graphiti, Sirius etc. The screencast doesn't even cover the rendering errors described in my previous blog post.



So what has gone wrong?

In my opinion, diagram editor behavior and editing metaphors haven't really changed since the first commits on the GEF project in 2002. Advances in UI design and usability have had almost no priority on Eclipse's graphical frameworks since then. They were built from a pure developer's perspective. So a lot of effort has been spent on:
  • Facilitating the development of new editors. This usually causes a restriction to very specific use cases. 
  • Establishing weird processes to implement new diagram editors. 
  • Repeatedly putting new abstraction layers on top of the existing ones. Hide the seemingly ugly or incomprehensible concepts of a base framework. The problem is to find better abstractions that don't leak. In the end you often have to learn both (or more) frameworks in order to use them. 
  • Building on top of existing frameworks with serious limitations, like integer coordinates, missing alpha channel, no hardware acceleration etc. 
  • Supporting very large diagrams. Yes, there are very big models. But diagrams with hundreds of nodes and connections only make good wallpapers.
  • Creating new compatibility APIs, e.g. to replace the rendering engine. These will limit the available functionality to the common minimum set of features of all backends. 
  • Changing a model graphically. Note the difference between editing a diagram – e.g. to make it look nicer – and changing the underlying model. Did you ever wonder why GEF Zest is the only Eclipse diagram framework with its own diagram layout algorithms and basic support for multi-touch gestures? 
Computers don't need diagrams. Diagrams are for humans. Their strength is to explain a part of a model in a very suggestive way. Taking the human user into focus changes the requirements for a graphical framework drastically. Issues like the following must have top priority:
  • Appealing visual design, 
  • Intuitive editing metaphors, 
  • Snappy behavior, 
  • Support for modern input devices, and 
  • The possibility for individual customization. 
How do we get there? Attend my talk Eclipse Diagram Editors - An Endangered Species at EclipseCon Europe for some propositions and an extensive demo.

EclipseCon Europe 2013

6 comments:

Oliver Reinhard said...

Jan, I couldn't agree more. The screencast demo is brilliant and says it all.

Andreas Mülder said...

That is perfectly true, and it is a lot of work to fix all these usability flaws in a graphical editor created with GEF / GMF.
Looking forward to your talk on EclipseCon...

Boris Brodski said...

Nice post! See you in Ludwigsburg.

Riardo CaWal said...

Nice post, Jan! I'd started to use EMF/GMF to develop an DSL editor and I'm really annoyed how EMF can be powerfull but also how all diagram editors lacks better polishing! You can't drag n'drop a node from pallete to canvas (the most expected way of ), there are no model slicers to show relevant information easily (like only superclasses or only classes that are referenced by the selected one) and faster ways to change methods or attributes. Something between GMF-based editors and OCLinEcore/Xtext editors.

Christian Schneider said...

You're absolutely right! That's why Xtext and KIELER / KLighD are such a good combination! See http://rtsys.informatik.uni-kiel.de/~kieler/videos/klighd/SCT.mp4 on http://rtsys.informatik.uni-kiel.de/confluence/x/swEF

Christian Schneider said...

You're absolutely right! That's why Xtext and KIELER / KLighD are such a good combination! See http://rtsys.informatik.uni-kiel.de/~kieler/videos/klighd/SCT.mp4 on http://rtsys.informatik.uni-kiel.de/confluence/x/swEF