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 <[email protected]> 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 > [email protected] > *[email protected] <[email protected]>* > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > On Sep 28, 2016, at 11:09 AM, Andrew Grande <[email protected]> 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 <[email protected]> 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:[email protected] <[email protected]>] >>> *Sent:* Tuesday, September 20, 2016 10:40 PM >>> *To:* [email protected] >>> *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 <[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]> >>> [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]> >>> [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]> >>> [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]> >>> [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 >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> -- >> *Scott Aslan = new WebDeveloper(* >> *{ "location": { "city": "Saint Cloud", "state": "FL", >> "zip": "34771" }, "contact": { "mobile": "(321)-591-0870 >> <%28321%29-591-0870>", "email": "[email protected] >> <[email protected]>", "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": "[email protected] <[email protected]>", "linkedin": "http://www.linkedin.com/in/scottaslan <http://www.linkedin.com/in/scottaslan>", "skype": "astechdev" }});*
