Re: NiFi Registry Create Item in the UI

[Rob Moran]

There could be more guidance to help someone get started when first
entering a brand new registry, like a link to launch the new bucket
dialog/workflow if the user has the special privilege. Being a special
privilege, however, I think it makes sense to direct the user to the Admin
section (wrench icon) and that all management aspects be performed there.

I think it would be really helpful if that user could create a new bucket
from the Save Flow Version dialog *in NiFi*. This way they would not even
have to access the Registry UI to create the bucket.

I agree with what Bryan described around flow import/export  functionality.

On Sun, Feb 11, 2018 at 9:11 AM Scott Aslan  wrote:

> One of the really cool features of the registry UI is the ability to deep
> link to a user, group, or bucket as well as the ability to deep link to
> view ALL of the items the current user is authorized to view, deep link
> to view ALL of the items in a specific bucket that the current user is
> authorized to view, and deep link to view a single item (flow). This
> functionality was geared towards enabling the user to search for an item
> (flow) by leveraging existing API calls but without building any real
> search capabilities into the UI or the backend. I agree that listing all
> items across buckets is not a very scalable approach and I could see a
> future where we replace this particular deep link (the main listing view
> of all items across all buckets) with a Google type search bar UX that
> will provide the user with a more complete search functionality. However, I
> also do still see value in being able to 'share' a link to be able to view
> a single item (flow) or to be able to share the contents of a bucket.
>
> -Scotty
>
> On Sat, Feb 10, 2018 at 4:29 PM, Andrew Grande  wrote:
>
>> Looking more at the UI. Not sure listing all items across buckets is a
>> very scalable approach. I expect to have lots and lots of buckets and many
>> many versions within a bucket. Having more of a 'nested' navigation, when
>> one can dive into a bucket, should provide for a more responsive UI and, as
>> a benefit, make a logical place for the New/Import button.
>>
>> And yes, working from the cli and taking a registry-first approach is
>> what drives all these activities.
>>
>> Cheers,
>> Andrew
>>
>> On Sat, Feb 10, 2018 at 2:41 PM Bryan Bende  wrote:
>>
>>> Andrew,
>>>
>>> I agree it is a little confusing, especially when you first enter a
>>> brand new registry instance with no data.
>>>
>>> However, the main page of the registry is not a listing of buckets, it
>>> is a listing of "items" across all buckets, where currently the only
>>> time of item is a flow. You then click on an item to see the details
>>> which includes the version list. So I'm not sure if having a "New
>>> Bucket" button on the main page makes sense when you aren't looking at
>>> the list of buckets.
>>>
>>> Regarding "New Flow" and "New Version"...
>>>
>>> Currently these are not options from with in the registry because they
>>> are expected to happen from NiFi. However, if we wanted to add the
>>> ability to export/import between registries (which I think we should)
>>> then I agree with your suggestions. There could be an "Import" button
>>> at the top-level which would create the flow and the first version as
>>> one operation, I view this as what you are calling "New Flow", and
>>> then there could be an "Import Version" action from the actions
>>> drop-down of a specific flow.
>>>
>>> -Bryan
>>>
>>>
>>>
>>> On Sat, Feb 10, 2018 at 11:39 AM, Andrew Grande 
>>> wrote:
>>> > Hi,
>>> >
>>> > I wanted to share some feedback and suggestions on the registry UI. It
>>> was a
>>> > little unnatural to look for a New Bucket button in the Settings menu.
>>> Same
>>> > sentiment with the Create Flow for when we expect to be able to import
>>> it in
>>> > the UI in the near future.
>>> >
>>> > How about making the (+) or New button much more prominent and where
>>> one
>>> > would expect it? I propose:
>>> >
>>> > New Bucket action in the top menu on the main screen. Can hide if no
>>> > permission.
>>> > New Flow button once inside the bucket.
>>> > New Flow version once inside a flow.
>>> >
>>> > The semantics of the action change between Create and Import depending
>>> on
>>> > the context, but the expected action button location should be the
>>> least
>>> > confusing.
>>> >
>>> > Makes sense?
>>> >
>>> > Andrew
>>>
>>
> --
Rob

Re: UI: feedback on the processor 'color' in NiFi 1.0

[Rob Moran]

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

Re: UI: feedback on the processor 'color' in NiFi 1.0

[Rob Moran]

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  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  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: flow status and counters feedback

[Rob Moran]

Andrew,

Thanks for the feedback on the status bar. Separation between each item
helps but realize after your comments how it can not feel like a single,
cohesive group of items. We could probably tighten things up a bit.

I think another part of this that could help would be to address some of
the discussion around awareness of stats updating. Being able to call more
attention (without being too intrusive) when stats change could help ease
some of the burden of having to routinely scan the status bar to look for
changes.

Also related, I would like to see us get a tooltip that is seen when you
hover anywhere on the status bar. That tooltip would provide more
descriptive text about what each item means. It would help new users learn
as well as provide detail and follow-on action when something is alerted.

Let's see what others think and then I can work on filing a jira to capture
thoughts.

Rob

On Mon, Sep 19, 2016 at 6:22 PM, Andrew Grande  wrote:

> Hi All,
>
> I'd like to provide some feedback on the NiFi 1.0 UI now that I had a
> chance to use it for a while, as well as pass along what I heard directly
> from other end users.
>
> Attached is a screenshot of a status bar right above the main flow canvas.
> The biggest difference from the 0.x UI is how much whitespace it now has
> between elements. To a point where it's not possible to quickly scan the
> state with a glance.
>
> Does anyone have other opinions? Can we adjust things slightly so they are
> easier on the eye an have less horizontal friction?
>
> Thanks!
> Andrew
>
>
>

[DISCUSS] Feature proposal: Streamline visual flow design

[Rob Moran]

There has been recent discussion around UI enhancements with the goal of
streamlining visual flow design. Please consider the following enhancements
and concepts for proposed solutions. Do you have any objections? If so,
please share your thoughts and ideas for alternate solutions to streamline
visual flow design in NiFi's GUI.


*Enhancement 1*Enable quicker, more efficient access to both known and not
yet known processors.


*Issue*The current interaction of dropping a processor on the graph and
being prompted with a dialog helps a user who does not know exactly which
one they need. However, as the number of processors increase, the current
methods of finding what you need become increasingly difficult. And for
those users who know exactly what processor they want, routine interaction
with the dialog becomes rather cumbersome.

*Concept for Proposed Solution*
Present logical groupings of processors to the user. Ideas include
usage-generated categories like ‘recent’ and ‘popular,’ along with
categories such as those defined by the Enterprise Integration Patterns
(e.g., mediate, route, transform) and perhaps further subcategories if
applicable. These options would be accessible from the main UI as well as
the add processor dialog.

Other ideas include 'pinning' processors you routinely use for quick
access, setting a default drag-n-drop processor, and assigning keyboard
shortcuts to quickly add a favorite to the graph.

Design decisions made here could also serve as a model for placing other
elements onto the graph such as templates.


*Enhancement 2*Provide visual distinction to processor types.


*Issue*When viewing a flow on the graph, all processor blocks look the
same. As a result, users must rely on processor names alone to interpret
what they are doing and how the given flow is working together.

*Concept for Proposed Solution*
Introduce some combination of iconography, unique styling, and more
descriptive labeling to processor blocks. As mentioned earlier, looking to
the Enterprise Integration Patterns could provide cues for visually
distinct icons and labeling. Unique styling could occur at various zoom
levels and/or screen resolution to better respond to user needs.

*Enhancement 3*
Give users the choice to be prompted immediately with a configuration
dialog after they place a processor, draw a connection, etc. on the graph.

*Issue*
Currently there is inconsistency with the interaction. Place a processor -
nothing. Draw a connection - configuration dialog pops up.

*Concept for Proposed Solution*
Part 1 - Decide on a consistent default behavior. Part 2 - Provide the user
the ability to reverse the behavior. One thought is to include a toggle in
each configuration dialog giving the user control over the behavior while
in context. Additionally, there could be a user preferences area where they
could make global changes. A user preferences area could come into play
with potential solutions proposed in Enhancement 1 as well.
-- 
Rob