After thinking on it a bit, I agree that Manish' suggestion could be a good idea as an option (the way /additionalDetails.html/ is an option). It would be easier if they were /.png/ files rather than formal icon files only with a "width x length" limit.

My two cents,

Russ

On 09/28/2016 12:57 AM, Manish Gupta 8 wrote:

I think one of the things that will really help in complex data flow from UI perspective is “colored icons” on each processor. Not sure if this already part of 1.0, but from my experience, icons definitely help a lot in quickly understanding complex flows. Those icons can be fixed (embedded within the nar) or may be dynamic (user defined icon file for different processors) – just a suggestion.

Regards,

Manish

*From:*Andrew Grande [mailto:apere...@gmail.com]
*Sent:* Tuesday, September 20, 2016 10:40 PM
*To:* users@nifi.apache.org
*Subject:* Re: UI: feedback on the processor 'color' in NiFi 1.0

No need to go wild, changing processor colors should be enough, IMO. PG and RPG are possible candidates, but they are different enough already, I guess.

What I heard quite often was to differentiate between regular processors, incoming sources of data and out only (data producers?). Maybe even with a shape?

Andrew

On Tue, Sep 20, 2016, 12:35 PM Rob Moran <rmo...@gmail.com <mailto:rmo...@gmail.com>> wrote:

    Good points. I was thinking a label would be tied to the group of
    components to which it was applied, but that could also introduce
    problems as things move and are added to a flow.

    So would you all expect to be able to change the color of every
    component type, or just processors?

    Andrew - your comment about coloring terminators red is
    interesting as well. What are some other parts of a flow you might
    use color to identify? Along with backpressure, we could explore
    other ways to call these things out so users do not come up with
    their own methods. Perhaps there are layer options, like on a map
    (e.g., "show terrain" or "show traffic").


    Rob

    On Tue, Sep 20, 2016 at 11:23 AM, Andrew Grande
    <apere...@gmail.com <mailto:apere...@gmail.com>> wrote:

        I agree. Labels are great for grouping, beyond PGs. Processor
        colors individually add value. E.g. flow terminator colored in
        red was a very common pattern I used. Besides, labels are not
        grouped with components, so moving things and re-arranging is
        a pain.

        Andrew

        On Tue, Sep 20, 2016, 11:21 AM Joe Skora <jsk...@gmail.com
        <mailto:jsk...@gmail.com>> wrote:

            Rob,

            The labelling functionality you described sounds very
            useful in general.  But, I miss the processor color too.

            I think labels are really useful for identifying groups of
            components and areas in the flow, but I worry that needing
            to use them in volume for processor coloring will increase
            the API and browser canvas load for elements that don't
            actually affect the flow.

            On Tue, Sep 20, 2016 at 10:40 AM, Rob Moran
            <rmo...@gmail.com <mailto:rmo...@gmail.com>> wrote:

                What if we promote the use of Labels as a way to
                highlight things. We could add functionality to expand
                their usefulness as a way to highlight things on the
                canvas. I believe that is their intended use.

                Today you can create a label and change its color to
                highlight single or multiple components. Even better
                you can do it for any component (not just processors).

                To expand on functionality, I'm imagining a context
                menu and palette action to "Label" a selected
                component or components. This would prompt a user to
                pick a background and add text which would place a
                label around everything once it's applied.


                Rob

                On Mon, Sep 19, 2016 at 6:42 PM, Jeff
                <jtsw...@gmail.com <mailto:jtsw...@gmail.com>> wrote:

                    I was thinking, in addition to changing the color
                    of the icon on the processor, that the color of
                    the drop shadow could be changed as well.  That
                    would provide more contrast, but preserve
                    readability, in my opinion.

                    On Mon, Sep 19, 2016 at 6:39 PM Andrew Grande
                    <apere...@gmail.com <mailto:apere...@gmail.com>>
                    wrote:

                        Hi All,

                        Rolling with UI feedback threads. This time
                        I'd like to discuss how NiFi 'lost' its
                        ability to change processor boxes color. I.e.
                        as you can see from a screenshot attached, it
                        does change color for the processor in the
                        flow overview panel, but the processor itself
                        only changes the icon in the top-left of the
                        box. I came across a few users who definitely
                        miss the old way. I personally think changing
                        the icon color for the processor doesn't go
                        far enough, especially when one is dealing
                        with a flow of several dozen processors, zooms
                        in and out often. The overview helps, but it's
                        not the same.

                        Proposal - can we restore how color selection
                        for the processor changed the actual
                        background of the processor box on the canvas?
                        Let the user go wild with colors and deal with
                        readability, but at least it's easy to spot
                        'important' things this way. And with
                        multi-tenant authorization it becomes a
                        poor-man's doc between teams, to an extent.

                        Thanks for any feedback,

                        Andrew


Reply via email to