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