Switchyard palette ordering in JBDS

Version 1

    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.

     

    Current OrderingProposed Ordering - Option AProposed Order - Option B

    Core

    • Component
    • Service
    • Reference
    • Promote

    Components

    • Generic component
    • Bean
    • Camel (Java)
    • Camel (XML)
    • Process (BPEL)
    • Process (BPMN)
    • Rules

    Components

    • Generic component
    • Bean
    • Camel (Java)
    • Camel (XML)
    • Process (BPEL)
    • Process (BPMN)
    • Rules
    • Promote

    Implementations

    • Bean
    • Camel (Java)
    • Camel (XML)
    • Process (BPEL)
    • Process (BPMN)
    • Rules

    Services and References

    • Service
    • Reference
    • Promote

    Services

    • Composite Service
    • Service Promoter
    • Atom
    • CXF
    • Camel
    • FTP
    • FTPS
    • File
    • HTTP
    • JCA
    • GMS
    • JPA
    • MQTT
    • Mail
    • Netty TCP
    • Netty UDP
    • REST
    • RSS
      SAP
    • SCA
    • SFTP
    • SOAP
    • SQL
    • Scheduling

    Bindings

    • Atom
    • CXF
    • Camel
    • FTP
    • FTPS
    • File
    • HTTP
    • JCA
    • GMS
    • JPA
    • MQTT
    • Mail
    • Netty TCP
    • Netty UDP
    • REST
    • RSS
      SAP
    • SCA
    • SFTP
    • SOAP
    • SQL
    • Scheduling

    Bindings

    • Atom
    • CXF
    • Camel
    • FTP
    • FTPS
    • File
    • HTTP
    • JCA
    • GMS
    • JPA
    • MQTT
    • Mail
    • Netty TCP
    • Netty UDP
    • REST
    • RSS
      SAP
    • SCA
    • SFTP
    • SOAP
    • SQL
    • Scheduling

    References

    • Composite Reference
    • Reference Promoter
    • Atom
    • CXF
    • Camel
    • FTP
    • FTPS
    • File
    • HTTP
    • JCA
    • GMS
    • JPA
    • MQTT
    • Mail
    • Netty TCP
    • Netty UDP
    • REST
    • RSS
      SAP
    • SCA
    • SFTP
    • SOAP
    • SQL
    • Scheduling

     

     

    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