So far there seems to be a couple in agreement to leave the add processor behavior as is. My use of *inconsistency* was referring the simple fact that behavior is different. Add a processor - no dialog; draw a connection - same type of dialog appears to take action. Perhaps we design a more intuitive way to quickly “configure” a connection when drawn. It could be a small in-place editor <http://ui-patterns.com/patterns/InplaceEditor> that appears when the connection is drawn allowing a quick, localized configuration to take place.
On Thu, Sep 10, 2015 at 2:42 PM Matt Gilman <[email protected]> wrote: > Brandon, > > Selecting which relationship and/or which input/output port a connection > is connected to is not what's in question here. That is absolutely required > when creating the connection. I would equate that to selecting the type of > processor. What was referenced initially as being inconsistent was the > presence of the Settings tab in the New Connection Dialog and not having > any available configuration in the New Processor Dialog. > > Matt > > On Thu, Sep 10, 2015 at 2:36 PM, Brandon DeVries <[email protected]> wrote: > >> Matt, >> >> If I understand what you're saying, it's that the goal is to get >> components on to the graph with as little input as possible. If so, then >> my argument is that a connection isn't a component in the same way a >> processor / group / funnel is, and applying the same rules for the sake of >> consistency would be unnecessarily confusing. Processors can conceivably >> have a lot of required configuration, and deferring that in favor of laying >> out the flow makes sense. A connection has one piece of required >> configuration... and it's a check box. If you're drawing a connection, you >> would think you'd know what relationship you were making the connection >> for. If you don't know what relationship you want, you probably shouldn't >> be making a connection. Deferring that configuration doesn't make sense to >> me. Again, obviously my opinion, but I don't see the gain. Additionally, >> I can imagine trying to troubleshoot a user's flow, and trying to explain >> that just because there is a line between the two processors doesn't >> actually mean they're connected... >> >> >> Brandon >> >> >> >> On Thu, Sep 10, 2015 at 1:50 PM Jennifer Barnabee < >> [email protected]> wrote: >> >>> Rob, >>> I also like enhancements 1 & 2. For the ability to pin processors or >>> pull recent/popular processors from a user-generated list, can we make that >>> something that is expandable/collapsible? While building a flow, I think >>> people might want that type of thing open. But then later, while working >>> with a flow, they'd want it out of the way. >>> Great ideas! >>> -Jenn >>> >>> On Thu, Sep 10, 2015 at 12:55 PM, Rob Moran <[email protected]> wrote: >>> >>>> There has been recent discussion around UI enhancements with the goal >>>> of streamlining visual flow design. Please consider the following >>>> enhancements and concepts for proposed solutions. Do you have any >>>> objections? If so, please share your thoughts and ideas for alternate >>>> solutions to streamline visual flow design in NiFi's GUI. >>>> >>>> >>>> *Enhancement 1*Enable quicker, more efficient access to both known and >>>> not yet known processors. >>>> >>>> >>>> *Issue*The current interaction of dropping a processor on the graph >>>> and being prompted with a dialog helps a user who does not know exactly >>>> which one they need. However, as the number of processors increase, the >>>> current methods of finding what you need become increasingly difficult. And >>>> for those users who know exactly what processor they want, routine >>>> interaction with the dialog becomes rather cumbersome. >>>> >>>> *Concept for Proposed Solution* >>>> Present logical groupings of processors to the user. Ideas include >>>> usage-generated categories like ‘recent’ and ‘popular,’ along with >>>> categories such as those defined by the Enterprise Integration Patterns >>>> (e.g., mediate, route, transform) and perhaps further subcategories if >>>> applicable. These options would be accessible from the main UI as well as >>>> the add processor dialog. >>>> >>>> Other ideas include 'pinning' processors you routinely use for quick >>>> access, setting a default drag-n-drop processor, and assigning keyboard >>>> shortcuts to quickly add a favorite to the graph. >>>> >>>> Design decisions made here could also serve as a model for placing >>>> other elements onto the graph such as templates. >>>> >>>> >>>> *Enhancement 2*Provide visual distinction to processor types. >>>> >>>> >>>> *Issue*When viewing a flow on the graph, all processor blocks look the >>>> same. As a result, users must rely on processor names alone to interpret >>>> what they are doing and how the given flow is working together. >>>> >>>> *Concept for Proposed Solution* >>>> Introduce some combination of iconography, unique styling, and more >>>> descriptive labeling to processor blocks. As mentioned earlier, looking to >>>> the Enterprise Integration Patterns could provide cues for visually >>>> distinct icons and labeling. Unique styling could occur at various zoom >>>> levels and/or screen resolution to better respond to user needs. >>>> >>>> *Enhancement 3* >>>> Give users the choice to be prompted immediately with a configuration >>>> dialog after they place a processor, draw a connection, etc. on the graph. >>>> >>>> *Issue* >>>> Currently there is inconsistency with the interaction. Place a >>>> processor - nothing. Draw a connection - configuration dialog pops up. >>>> >>>> *Concept for Proposed Solution* >>>> Part 1 - Decide on a consistent default behavior. Part 2 - Provide the >>>> user the ability to reverse the behavior. One thought is to include a >>>> toggle in each configuration dialog giving the user control over the >>>> behavior while in context. Additionally, there could be a user preferences >>>> area where they could make global changes. A user preferences area could >>>> come into play with potential solutions proposed in Enhancement 1 as well. >>>> -- >>>> Rob >>>> >>> > -- Rob
