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 <[email protected] <[email protected]>>* > *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 <[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 >
