nifi-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Moran <>
Subject Re: [DISCUSS] Feature proposal: Streamline visual flow design
Date Fri, 13 Nov 2015 16:04:44 GMT
Thanks for your input Charlie! No worries – I don't think there is anything
you can do from the archive. I've responded from the original to loop you
in and included your message below.

*Charlie Frasure < <>>*
> *9:13 AM (1 hour ago)*
> *to users*
> *Apologies, not sure how to properly respond to an old thread.  (Maybe
> that's the idea.)  I was looking through the archives before posting some
> usability comments about the UI and turned up a couple of threads in
> September.*
> *If we did automatically open the configuration screen when a processor
> was dropped on the canvas, a quick press of ESC seems to back out nicely.
> A possible compromise for the processor configuration could be a
> double-click to open behavior, as it seems this action is not currently
> assigned.  Better yet, a user-configurable double click action (start/stop,
> configure, data provenance, etc) would be nice.*
> *The other enhancements mentioned would be great as well.*

On Thu, Sep 10, 2015 at 12:55 PM, Rob Moran <> 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

View raw message