Switchyard Palette

The switchyard palette grouping and ordering was brought into question during a usability review of the software.  The question was brought up as to whether a different grouping, naming, and ordering scheme would lend itself easier to use and more intuitive to users.  The following table captures the current ordering and two proposed ordering options to consider in place of the current one.

Proposed Option A discussion:

By moving the implementations in line with the generic component, you are associating these items together more closely as that is what the user needs to work with together.  Also, it more easily lends itself to users understanding that they can either pull in a generic component and define its type later, or they can just drag in the type of implementation they want (Camel for instance) instead of doing a two-click-and-drag process.

The services, references, and bindings are then put into two groupings, one for the objects (service, reference, promote), and one for the bindings you can put on the services and references.

Proposed Option B discussion:

This option leaves "promote" in the components section with the idea that you are always promoting objects only when you have a component in place.

It then breaks Services and References into two buckets, with the generic object and the bindings that work with that object in the group.  The idea here is that you are likely working with either a service or a reference, so placing the focus on those objects while repeating bindings allows users to focus on what they are trying to create rather than our idea of logical groupings of the objects.  This option also adds in more specificity to help users with the Composite object an a promoter object as two distinct options as it might not be clear to users that they can drag and drop the generic reference/service objects either on the Composite or onto a Component. 

Other ideas/questions

• Would we be able to "light up" potential valid drop locations when dragging and object off of the palette rather than waiting for users to pull it over every potential location?
• Uncertain of some of the terminology I chose above, would like SME review of it to see if it aligns when what users expect to see

Next Steps

• Get engineering and SME feedback on proposed palette grouping options
• Put together a quick usability test with new & existing Switchyard users to see which organizations work best