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?
- Appealing visual design,
- Intuitive editing metaphors,
- Snappy behavior,
- Support for modern input devices, and
- The possibility for individual customization.
8 comments:
Jan, I couldn't agree more. The screencast demo is brilliant and says it all.
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...
Nice post! See you in Ludwigsburg.
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.
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
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
I prefer having the diagram drawn and posted here using a diagram software .
Nice, but just drawing a diagram (=picture) is not the same as having something backed by and connected to a model (=semantics).
Post a Comment