After taking a bit of a breather and a look at the editor with fresh eyes (and some discussions with Brian), I'd like to propose a few cosmetic changes to the editor:
I think the editor could convey more information at a glance if the decorators on the shapes were modified to be context sensitive. A simple example would be the "+" used to identifiy implementations on a component. If that "+" were changed to reflect the type of implementation, one could easily tell what technology is used to implement the component: bean, bpmn, bpel, camel (xml or java), etc. This same principle can be carried over to interfaces and bindings as well (although bindings present a special challenge in that there may be more than one binding on a service/reference).
Tool Palette Structure
The tool palette is growing as we continue to flesh out support for SwitchYard's plethora of support impelemtation and binding types. The tools in the "Implementation" section almost exactly match the tools in the component section. In the end, does this duplication add to the user experience? I propose reorganizing the tools to something like the following:
- Service - composite or component depending on the target shape
- Reference - composite or component depending on the target shape
- Promote - service or reference depending on the connection source
- Implementations - create component or set implementation depending on target shape
- Camel (Java)
- Camel (XML)
- Process (BPEL)
- Process (BPMN)
- Rule (DRL)
To elaborate, using "Implementations" as an example, dropping an implementation on the "composite" shape in the canvas would create a new component using that implementation type. Dropping the same implementation tool on a "component" shape would change that component's implementation type. That said, I'm not a fan of "Implementations," but I'm no wordsmith either, so... I also wonder if there's any benefit to changing "Bindings" to "Endpoints." Thoughts, opinions, suggestions?