nifi-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Moran <rmo...@gmail.com>
Subject Re: [DISCUSS] Feature proposal: Streamline visual flow design
Date Thu, 10 Sep 2015 19:09:44 GMT
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 <matt.c.gilman@gmail.com> 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 <brd@jhu.edu> 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 <
>> jennifer.barnabee@gmail.com> 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 <rmoran@gmail.com> 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

Mime
View raw message