You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@nifi.apache.org by Andrew Grande <ap...@gmail.com> on 2016/09/19 22:38:58 UTC
UI: feedback on the processor 'color' in NiFi 1.0
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
Re: UI: feedback on the processor 'color' in NiFi 1.0
Posted by Scott Aslan <sc...@gmail.com>.
Does the Birdseye view as a layer not solve most of the 'simple
functionality' being requested by users?
On Wed, Sep 28, 2016 at 2:21 PM, Andy LoPresto <al...@apache.org> wrote:
> I think Rob’s layer idea is also very useful. I agree with Scott
> elaborating on it. Different user roles are interested in different metrics
> (a “designer” laying out components and solving a transformation problem
> vs. a “monitor” watching realtime data flow and keeping operations stable).
> As the available features grow, making them usable, understandable, and
> performant is very important. New roles are adopting NiFi as well, so there
> will be a balance between conservative adherence to previous user
> experience and growing the reach and audience of the project.
>
> Andy LoPresto
> alopresto@apache.org
> *alopresto.apache@gmail.com <al...@gmail.com>*
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
>
> On Sep 28, 2016, at 11:09 AM, Andrew Grande <ap...@gmail.com> wrote:
>
> I think we are over designing. I like the big ideas, but really would love
> simple functionality that was there before, based on user reactions I
> observed first-hand.
>
> Andrew
>
> On Wed, Sep 28, 2016, 2:03 PM Scott Aslan <sc...@gmail.com> wrote:
>
>> Rob - I really like your idea of layers! We could have a 'traffic' layer
>> that could highlight areas of back pressure while the data is flowing. We
>> could even allow the user to customize the threshold for warnings or alert
>> values as well as the colors used for the different states of data flowing
>> (E.g. green means data flowing normally, yellow is between the two user
>> defined thresholds, and red would be over)...maybe this layer is just the
>> color of the drop shadow for each element on the canvas and this view can
>> be toggled on or off.
>>
>> Andrew - I can def see the value in coloring different phases of a flow (E.g.
>> flow terminator colored in red). I wonder if we could create a list of
>> these common phases and either let the user assign the processor/element to
>> a phase while they are configuring it or maybe we can automatically detect
>> certain well defined phases. Would also be cool to allow the user to input
>> custom colors for each phase and also to be able to toggle the view on/off.
>>
>> Andrew - Also on the topic of coloring elements on the canvas....I was
>> thinking about zooming out on the canvas and how quickly the current UX of
>> colored icons becomes unhelpful...meanwhile the Birdseye view does color
>> the processors in a very useful way when zoomed out...would it make sense
>> to switch out the canvas for the Birdseye view once we have sufficiently
>> zoomed out? I think this would satisfy most of the cases for
>> needing/wanting color. Also, nifi could allow users to toggle
>> the Birdseye view as one of the 'layers' even when they are zoomed in...
>>
>> -Scott
>>
>> On Wed, Sep 28, 2016 at 9:41 AM, Russell Bateman <russell.bateman@
>> perfectsearchcorp.com> wrote:
>>
>>> 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:aperepel@gmail.com <ap...@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 <rm...@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 <ap...@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 < <js...@gmail.com>
>>> jskora@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 < <rm...@gmail.com>
>>> rmoran@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 < <jt...@gmail.com>
>>> jtswork@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 < <ap...@gmail.com>
>>> aperepel@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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> *Scott Aslan = new WebDeveloper(*
>> *{ "location": { "city": "Saint Cloud", "state": "FL",
>> "zip": "34771" }, "contact": { "mobile": "(321)-591-0870
>> <%28321%29-591-0870>", "email": "scottyaslan@gmail.com
>> <sc...@gmail.com>", "linkedin":
>> "http://www.linkedin.com/in/scottaslan
>> <http://www.linkedin.com/in/scottaslan>", "skype": "astechdev"
>> }});*
>>
>
>
--
*Scott Aslan = new WebDeveloper(*
*{ "location": { "city": "Saint Cloud", "state": "FL",
"zip": "34771" }, "contact": { "mobile":
"(321)-591-0870", "email": "scottyaslan@gmail.com
<sc...@gmail.com>", "linkedin":
"http://www.linkedin.com/in/scottaslan
<http://www.linkedin.com/in/scottaslan>", "skype": "astechdev"
}});*
Re: UI: feedback on the processor 'color' in NiFi 1.0
Posted by Andy LoPresto <al...@apache.org>.
I think Rob’s layer idea is also very useful. I agree with Scott elaborating on it. Different user roles are interested in different metrics (a “designer” laying out components and solving a transformation problem vs. a “monitor” watching realtime data flow and keeping operations stable). As the available features grow, making them usable, understandable, and performant is very important. New roles are adopting NiFi as well, so there will be a balance between conservative adherence to previous user experience and growing the reach and audience of the project.
Andy LoPresto
alopresto@apache.org
alopresto.apache@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
> On Sep 28, 2016, at 11:09 AM, Andrew Grande <ap...@gmail.com> wrote:
>
> I think we are over designing. I like the big ideas, but really would love simple functionality that was there before, based on user reactions I observed first-hand.
>
> Andrew
>
>
> On Wed, Sep 28, 2016, 2:03 PM Scott Aslan <scottyaslan@gmail.com <ma...@gmail.com>> wrote:
> Rob - I really like your idea of layers! We could have a 'traffic' layer that could highlight areas of back pressure while the data is flowing. We could even allow the user to customize the threshold for warnings or alert values as well as the colors used for the different states of data flowing (E.g. green means data flowing normally, yellow is between the two user defined thresholds, and red would be over)...maybe this layer is just the color of the drop shadow for each element on the canvas and this view can be toggled on or off.
>
> Andrew - I can def see the value in coloring different phases of a flow (E.g. flow terminator colored in red). I wonder if we could create a list of these common phases and either let the user assign the processor/element to a phase while they are configuring it or maybe we can automatically detect certain well defined phases. Would also be cool to allow the user to input custom colors for each phase and also to be able to toggle the view on/off.
>
> Andrew - Also on the topic of coloring elements on the canvas....I was thinking about zooming out on the canvas and how quickly the current UX of colored icons becomes unhelpful...meanwhile the Birdseye view does color the processors in a very useful way when zoomed out...would it make sense to switch out the canvas for the Birdseye view once we have sufficiently zoomed out? I think this would satisfy most of the cases for needing/wanting color. Also, nifi could allow users to toggle the Birdseye view as one of the 'layers' even when they are zoomed in...
>
> -Scott
>
> On Wed, Sep 28, 2016 at 9:41 AM, Russell Bateman <russell.bateman@perfectsearchcorp.com <ma...@perfectsearchcorp.com>> wrote:
> 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:aperepel@gmail.com <ma...@gmail.com>]
>> Sent: Tuesday, September 20, 2016 10:40 PM
>> To: users@nifi.apache.org <ma...@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 <rmoran@gmail.com <ma...@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 <aperepel@gmail.com <ma...@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 < <ma...@gmail.com>jskora@gmail.com <ma...@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 < <ma...@gmail.com>rmoran@gmail.com <ma...@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 < <ma...@gmail.com>jtswork@gmail.com <ma...@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 < <ma...@gmail.com>aperepel@gmail.com <ma...@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
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
> --
> Scott Aslan = new WebDeveloper(
> {
> "location": {
> "city": "Saint Cloud",
> "state": "FL",
> "zip": "34771"
> },
> "contact": {
> "mobile": "(321)-591-0870",
> "email": "scottyaslan@gmail.com <ma...@gmail.com>",
> "linkedin": "http://www.linkedin.com/in/scottaslan <http://www.linkedin.com/in/scottaslan>",
> "skype": "astechdev"
> }
> });
Re: UI: feedback on the processor 'color' in NiFi 1.0
Posted by Andrew Grande <ap...@gmail.com>.
I think we are over designing. I like the big ideas, but really would love
simple functionality that was there before, based on user reactions I
observed first-hand.
Andrew
On Wed, Sep 28, 2016, 2:03 PM Scott Aslan <sc...@gmail.com> wrote:
> Rob - I really like your idea of layers! We could have a 'traffic' layer
> that could highlight areas of back pressure while the data is flowing. We
> could even allow the user to customize the threshold for warnings or alert
> values as well as the colors used for the different states of data flowing
> (E.g. green means data flowing normally, yellow is between the two user
> defined thresholds, and red would be over)...maybe this layer is just the
> color of the drop shadow for each element on the canvas and this view can
> be toggled on or off.
>
> Andrew - I can def see the value in coloring different phases of a flow (E.g.
> flow terminator colored in red). I wonder if we could create a list of
> these common phases and either let the user assign the processor/element to
> a phase while they are configuring it or maybe we can automatically detect
> certain well defined phases. Would also be cool to allow the user to input
> custom colors for each phase and also to be able to toggle the view on/off.
>
> Andrew - Also on the topic of coloring elements on the canvas....I was
> thinking about zooming out on the canvas and how quickly the current UX of
> colored icons becomes unhelpful...meanwhile the Birdseye view does color
> the processors in a very useful way when zoomed out...would it make sense
> to switch out the canvas for the Birdseye view once we have sufficiently
> zoomed out? I think this would satisfy most of the cases for
> needing/wanting color. Also, nifi could allow users to toggle
> the Birdseye view as one of the 'layers' even when they are zoomed in...
>
> -Scott
>
> On Wed, Sep 28, 2016 at 9:41 AM, Russell Bateman <
> russell.bateman@perfectsearchcorp.com> wrote:
>
>> 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:aperepel@gmail.com <ap...@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 <rm...@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 <ap...@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 < <js...@gmail.com>
>> jskora@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 < <rm...@gmail.com>
>> rmoran@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 < <jt...@gmail.com>
>> jtswork@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 < <ap...@gmail.com>
>> aperepel@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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
> --
> *Scott Aslan = new WebDeveloper(*
> *{ "location": { "city": "Saint Cloud", "state": "FL",
> "zip": "34771" }, "contact": { "mobile":
> "(321)-591-0870", "email": "scottyaslan@gmail.com
> <sc...@gmail.com>", "linkedin":
> "http://www.linkedin.com/in/scottaslan
> <http://www.linkedin.com/in/scottaslan>", "skype": "astechdev"
> }});*
>
Re: UI: feedback on the processor 'color' in NiFi 1.0
Posted by Scott Aslan <sc...@gmail.com>.
Rob - I really like your idea of layers! We could have a 'traffic' layer
that could highlight areas of back pressure while the data is flowing. We
could even allow the user to customize the threshold for warnings or alert
values as well as the colors used for the different states of data flowing
(E.g. green means data flowing normally, yellow is between the two user
defined thresholds, and red would be over)...maybe this layer is just the
color of the drop shadow for each element on the canvas and this view can
be toggled on or off.
Andrew - I can def see the value in coloring different phases of a flow (E.g.
flow terminator colored in red). I wonder if we could create a list of
these common phases and either let the user assign the processor/element to
a phase while they are configuring it or maybe we can automatically detect
certain well defined phases. Would also be cool to allow the user to input
custom colors for each phase and also to be able to toggle the view on/off.
Andrew - Also on the topic of coloring elements on the canvas....I was
thinking about zooming out on the canvas and how quickly the current UX of
colored icons becomes unhelpful...meanwhile the Birdseye view does color
the processors in a very useful way when zoomed out...would it make sense
to switch out the canvas for the Birdseye view once we have sufficiently
zoomed out? I think this would satisfy most of the cases for
needing/wanting color. Also, nifi could allow users to toggle
the Birdseye view as one of the 'layers' even when they are zoomed in...
-Scott
On Wed, Sep 28, 2016 at 9:41 AM, Russell Bateman <
russell.bateman@perfectsearchcorp.com> wrote:
> 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:aperepel@gmail.com <ap...@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 <rm...@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 <ap...@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 < <js...@gmail.com>
> jskora@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 < <rm...@gmail.com>
> rmoran@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 < <jt...@gmail.com>
> jtswork@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 < <ap...@gmail.com>
> aperepel@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
>
>
>
>
>
>
>
>
>
--
*Scott Aslan = new WebDeveloper(*
*{ "location": { "city": "Saint Cloud", "state": "FL",
"zip": "34771" }, "contact": { "mobile":
"(321)-591-0870", "email": "scottyaslan@gmail.com
<sc...@gmail.com>", "linkedin":
"http://www.linkedin.com/in/scottaslan
<http://www.linkedin.com/in/scottaslan>", "skype": "astechdev"
}});*
Re: UI: feedback on the processor 'color' in NiFi 1.0
Posted by Russell Bateman <ru...@perfectsearchcorp.com>.
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 \u201ccolored icons\u201d 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) \u2013 just a suggestion.
>
> Regards,
>
> Manish
>
> *From:*Andrew Grande [mailto:aperepel@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 <rmoran@gmail.com
> <ma...@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
> <aperepel@gmail.com <ma...@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 <jskora@gmail.com
> <ma...@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
> <rmoran@gmail.com <ma...@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
> <jtswork@gmail.com <ma...@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
> <aperepel@gmail.com <ma...@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
>
RE: UI: feedback on the processor 'color' in NiFi 1.0
Posted by Manish Gupta 8 <mg...@sapient.com>.
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:aperepel@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 <rm...@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 <ap...@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 <js...@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 <rm...@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 <jt...@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 <ap...@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
Re: UI: feedback on the processor 'color' in NiFi 1.0
Posted by Andrew Grande <ap...@gmail.com>.
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 <rm...@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 <ap...@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 <js...@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 <rm...@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 <jt...@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 <ap...@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
>>>>>>
>>>>>
>>>>
>>>
>
Re: UI: feedback on the processor 'color' in NiFi 1.0
Posted by Rob Moran <rm...@gmail.com>.
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 <ap...@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 <js...@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 <rm...@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 <jt...@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 <ap...@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
>>>>>
>>>>
>>>
>>
Re: UI: feedback on the processor 'color' in NiFi 1.0
Posted by Andrew Grande <ap...@gmail.com>.
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 <js...@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 <rm...@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 <jt...@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 <ap...@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
>>>>
>>>
>>
>
Re: UI: feedback on the processor 'color' in NiFi 1.0
Posted by Joe Skora <js...@gmail.com>.
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 <rm...@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 <jt...@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 <ap...@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
>>>
>>
>
Re: UI: feedback on the processor 'color' in NiFi 1.0
Posted by Rob Moran <rm...@gmail.com>.
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 <jt...@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 <ap...@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
>>
>
Re: UI: feedback on the processor 'color' in NiFi 1.0
Posted by Jeff <jt...@gmail.com>.
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 <ap...@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
>