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> 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>
> 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> 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> 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> 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>
>>>>> 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