Proposed SwitchYard Editor UI Changes

[rcernich]

Hey all,

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:

Decorator Icons

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:

• Generic
  • Component
  • 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
  • Bean
  • Camel (Java)
  • Camel (XML)
  • Process (BPEL)
  • Process (BPMN)
  • Rule (DRL)
• Bindings
  • File
  • FTP
  • JCA
  • JMS
  • Netty
  • SOAP
  • ....

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?

Best,

Rob

[rcernich]

Regarding the decorator icons, the icons selected should be the same as or closely match existing icons in the Eclipse tooling used to identify corresponding resource types (e.g. Java interfaces, WSDL files, BPMN process files, etc.).  Obviously, if there isn't an existing icon (e.g. Camel, SOAP), I think we can choose what we like.

[kcbabo]

Agree on decorator icons.  Not sure about the Tool Palette structure changes.  Seems like it could be good, but need to let it digest a bit.

[rcernich]

I'd also like to propose using property dialogs as opposed to the properties view for editing complex items (e.g. bindings).  The main problems I have with some of the property sheets is their size (although they don't take up as much screen space as some of the bpmn property sheets) and atomicity of changes, i.e. each field modified is a change, but multiple fields can be changed in a property dialog and committed to the model as a single unit.

If we go this route, we may also want to modify the double-click listener associated with Service and Reference to open the property dialog instead of the related interface file (wsdl, java).

That said, we should probably add actions to the shapes like: (as appropriate)

• Open Interface
• Open Implementation
• Properties

[kcbabo]

After thinking about this a bit more, I think the tool palette change is worth a go.

[kcbabo]

+1 on a dialog.  In theory, using property sheets might be faster because you can bounce around and always have the view open.  In practice, it's a pain because it's always squashed at the bottom and I find myself changing focus in the editor too much.  I just assused this was an Eclipse law of usability that we weren't allowed to violate.  Big +1 on atomic update for multiple changes.

Not so sure on the double-click change to interface, *unless* you can get equivalent linking through a right-click menu (e.g. RC -> Open Interface).  If that were the case, then I would be +1 to this as well.

One last thing - I'm officially not a fan of opening the implementation editor automatically for new service components.  When I use the editor and demo it, I constantly find myself switching back to the model from the implementation editor just to get my bearings.  I think it's easy enough to double-click on the service component to open the appropriate implementation editor.

[rcernich]

Sounds good.  It's easy enough to change open on create (we don't do it when adding an implementation to an existing component).  We can (and should) "reveal" the new resource in the navigator when it is created (similar to what we do with java2wsdl).

Do you want these for 0.5?

[kcbabo]

Agreed.  When you say "these", do you mean just {don't open on create, reveal resource in navigator} ?

[rcernich]

I should clarify, do you want the following in 0.5:

• Palette restructuring
• No open on create
• Menu items for open

I don't think it's possible to get property dialogs worked out in a day or two, especially given how many we'd have to code up.

[kcbabo]

Let's just nuke open on create for 0.5.  The other two can go in 0.6.  I'm hoping to make next week a relaxing release week. 

[rcernich]

I've added a screenshot of the new palette to SWITCHYARD-964.  What do you think?  Yea/nay?

[kcbabo]

Like.  Added a question to the JIRA, but I'll paste it here as well:

Looks good to me. Can the "generic" service and reference icons be dropped onto a component or a composite?