nifi-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Moran <rmo...@gmail.com>
Subject Re: Nifi UI Enhancements
Date Sat, 05 Sep 2015 13:51:03 GMT
I'll work on putting something together for discussion.

Rob
On Sep 4, 2015 11:20 PM, "Joe Witt" <joe.witt@gmail.com> wrote:

> Issue #1: Make it easier/more intuitive to find the desired processor
>
> Yep.  Several things we can do here.  All of the suggestions so far on
> this thread I personally like.
>
> Issue #2: Provide visual distinction to processors
>
> Yep.  Wanted this as far back as 2010.  In fact, the plan was to use
> the Enterprise Integration Patterns as the basis for it.  By having
> developers annotate the processor with its 'type' which would be
> 'route, transform, mediate' or more specific classifications thereof
> we could provide an intuitive icon.  But then we got tripped up on how
> much real estate it would take up, what to do if multiple
> classifications fit, etc..  And the idea just stalled.  If we did this
> though it would offer additional ways to tackle #1 as well.
>
> Issue #3:
>
> This is a user preference thing.
>
>     'I don't build flows often, but when I do I prefer breadth first'.
>
> As Rob points out some users prefer to lay the foundation first when
> building flows and then go back in and configure the details of each
> component.  If one is more of a depth first thinker the approach of
> having the config dialogue popup would be preferred.  Now having said
> this it is humorous to note that when drawing connections it does
> immediately go to a configuration dialogue and that is quite nice.
> Hmmm I might be changing my mind about which I prefer as I write
> this...
>
> --
>
> So, ultimately this thread should probably turn into a feature
> proposal around 'Streamlining visual flow design' perhaps and then
> spawn off a series of JIRAs.  Anyone want to volunteer to do that?
>
> Thanks
> Joe
>
> On Fri, Sep 4, 2015 at 7:02 PM, Rob Moran <rmoran@gmail.com> wrote:
> > Rick - you bring up several very good usability issues.
> >
> > Re: Issue #1:
> >
> > I too believe the ‘generic processor picker’ is functional and should
> > remain. It’s useful for someone who doesn’t know what they need. However,
> > you’re right that there can be more efficient interaction for those users
> > who already know what they want.
> >
> > I like where Alan was headed with his thoughts - recognition of last
> used,
> > popular, or set by preference. To expand on user preferences, perhaps the
> > ability to set a default type accessed by a single click, or access
> > favorites via keyboard shortcuts. Also as Alan and others mentioned,
> logical
> > groupings of processors could help as well - this could be available as a
> > traditional menu from the current processor icon.
> >
> > Re: Issue #2:
> >
> > I agree. Unique icons and/or styling in general are ways we could start
> to
> > differentiate parts of a flow.
> >
> > I really like the idea of a more responsive interface that adapts to
> scaling
> > - only particular details of a component may be relevant at certain zoom
> > levels.
> >
> > Re: Issue #3:
> >
> > That’s a tough one for me. I understand your view and it makes sense - if
> > some standard configuration steps are necessary why not prompt them from
> the
> > start. However, I could also see someone building a flow and just want to
> > sort of visually create, or map out the entire flow without being
> > interrupted each time to configure. Again, maybe it comes down to a
> choice
> > (i.e., user preference).
> >
> > You also brought up usability studies and Issue #3 would be a good one to
> > gauge user opinion on.
> >
> >
> > On Fri, Sep 4, 2015 at 6:45 PM Alan Jackoway <alanj@cloudera.com> wrote:
> >>
> >> Hello,
> >>
> >> I think that icons and opening the properties when you drop a processor
> >> (at least as an option) are both very good ideas. For the icons NiFi
> might
> >> have to deal with a little bit of licensing, but I'm sure we can figure
> that
> >> out. I think it should be somewhat easy for NiFi to provide some
> standard
> >> icons.
> >>
> >> I personally like the big boxes because I'm often interested in the
> >> numbers they contain, but since NiFi already has a zoom tool, I think an
> >> all-icon view when you zoom out far enough or some other kind of
> condensed
> >> view would make a lot of sense. In our deployment, we use process groups
> >> pretty heavily to augment the zooming, so I definitely understand how
> the UI
> >> can get overwhelmed by processors.
> >>
> >> Do you have specific ideas on how to improve the processor selector? The
> >> filtering usually works for me, but I can see what you're saying about
> it
> >> getting harder as the project expands. Here are two ideas off the top
> of my
> >> head:
> >> * Set favorite processors explicitly, and pin them to the top.
> >> * Sort processors based on things like "most commonly used", "last
> used",
> >> and "type/icon" (tying in with your previous idea).
> >>
> >> Alan
> >>
> >> On Sat, Sep 5, 2015 at 12:03 AM, Rick Braddy <rbraddy@softnas.com>
> wrote:
> >>>
> >>> Good point.
> >>>
> >>>
> >>>
> >>> I was not suggesting the generic processor picker be done away with at
> >>> all, as it’s very functional, just adding a more convenient way to
> drag and
> >>> drop processors that are most commonly used onto the canvas and adding
> an
> >>> iconic representation to processors.
> >>>
> >>>
> >>>
> >>> Rick
> >>>
> >>>
> >>>
> >>> From: Ian Ragsdale [mailto:ian.ragsdale@gmail.com]
> >>> Sent: Friday, September 04, 2015 3:48 PM
> >>> To: users@nifi.apache.org
> >>> Subject: Re: Nifi UI Enhancements
> >>>
> >>>
> >>>
> >>> Another way to look at silence is a lack of disagreement. :) I haven't
> >>> yet used NiFi enough to have these things become annoyances, but I
> can't
> >>> disagree with any of those general suggestions.
> >>>
> >>>
> >>>
> >>> A 2x2 grid of processors down the side that would let you choose the
> >>> processor type *before* dragging it onto the canvas sounds great to me,
> >>> assuming that the processors have distinctive icons. I think there
> would
> >>> likely still be a need for the processor picker, but the common use
> case
> >>> where you know exactly what you want to add could definitely be sped
> up.
> >>>
> >>>
> >>>
> >>> - Ian
> >>>
> >>>
> >>>
> >>> On Sep 4, 2015, at 4:37 PM, Rick Braddy <rbraddy@softnas.com> wrote:
> >>>
> >>>
> >>>
> >>> Okay.  Looks like I’m the only one who thinks this is an issue…
> >>>
> >>>
> >>>
> >>> Onward.
> >>>
> >>>
> >>>
> >>> From: Rick Braddy [mailto:rbraddy@softnas.com]
> >>> Sent: Wednesday, September 02, 2015 11:23 PM
> >>> To: users@nifi.apache.org
> >>> Subject: Nifi UI Enhancements
> >>>
> >>>
> >>>
> >>> After using Nifi for some weeks now, I have an enhancement request to
> >>> recommend for the UI that I believe will dramatically improve the
> usability.
> >>>
> >>>
> >>>
> >>> Before I jump into the problems, let me say this about the UI.  It’s
> very
> >>> intuitive, easy to learn and consistent.  It’s also very clean and
> >>> attractive from an appearance standpoint.  As described below, there
> are
> >>> some areas that are becoming tedious with dozens of processors today,
> and
> >>> that will become acute from a usability perspective if untreated.
> >>>
> >>>
> >>>
> >>> The Challenges
> >>>
> >>>
> >>>
> >>> Issue #1 – Processors take too much time to select and configure
> >>> initially
> >>>
> >>>
> >>>
> >>> Overall, the Nifi UI is fantastic from an ease of use perspective;
> >>> however, there is one area that’s problematic and that will become
> >>> increasingly challenging… adding new processor blocks and choosing the
> >>> processor type.
> >>>
> >>>
> >>>
> >>> The primary issue stems from the lengthy list of processors to scroll
> >>> through and pick from.  The filter cloud is helpful, but with time
> even this
> >>> mechanism is reaching its limits, as the number of processors
> continues to
> >>> grow with the success of the project.
> >>>
> >>>
> >>>
> >>> There needs to be an easier, more productive way to simply drag and
> drop
> >>> processors to the canvass.
> >>>
> >>>
> >>>
> >>> Issue #2 – Processor blocks all look the same instead of being more
> >>> visually distinct and easily recognizable by function
> >>>
> >>>
> >>>
> >>> Our brains are wired for rapid pattern recognition of images, text
> takes
> >>> more cycle of higher-level reasoning to interpret.
> >>>
> >>>
> >>>
> >>> Because processor blocks are shown, by default, with their I/O
> statistics
> >>> and textual names, they all kind of look the same.  This “runtime
> view” is
> >>> great for troubleshooting or monitoring, but not as useful when
> building
> >>> complex data flows.  An “iconic view” would provide an easier way to
> >>> visualize the structure and intent behind each graph and its flows,
> >>> especially when developing the flows.
> >>>
> >>>
> >>>
> >>> Additionally, an icon representing each type of processor block would
> >>> make it much faster and easier to recognize what that processor block
> does,
> >>> versus having to read and interpret each one individually (especially
> for
> >>> complex graphs).  Processors that handle files could be represented by
> a
> >>> “file” icon, Hadoop by a Hadoop icon, HTTP by a globe icon, etc.
> >>>
> >>>
> >>>
> >>> #3  - When dropping a new processor, open its Properties dialog
> >>> automatically (to avoid right-click, then “Configure” and choose tab
> steps)
> >>>
> >>>
> >>>
> >>> Every time a new processor is dropped onto the canvass, we must go
> >>> through the process to select its type.  Then, the dialog closes and
> we’re
> >>> usually left with an incomplete processor with errors.  We know that
> most
> >>> processors require some initial Property configuration, so why not just
> >>> proceed to that dialog after choosing the processor type, so can finish
> >>> configuring it, then apply so we have a processor that’s ready to
> integrate?
> >>>
> >>>
> >>>
> >>> Potential Solutions
> >>>
> >>>
> >>>
> >>> Visio has a great model for addressing #1 that I would propose as a
> >>> starting point for resolving this issue – use of a “tool palette”
that
> snaps
> >>> into place on the left side of the canvass.  Each group of tools (e.g.,
> >>> file-related processors, Hadoop processors, HTTP processors, etc.)
> would be
> >>> grouped together within a toolbox area, with an icon representing each
> >>> tool/processor with a brief description of each tool.
> >>>
> >>>
> >>>
> >>> As with Visio, the user would open up several commonly used toolboxes
> and
> >>> then just drag and drop a tool from the toolbox directly onto the
> canvass,
> >>> with no need to select the processor type (each processor is shown as a
> >>> unique type in its toolbox).  This approach is very familiar to Visio
> users
> >>> and other tools that operate in a similar manner with object drag and
> drop.
> >>> Scrolling through lengthy lists is time-consuming and becomes tedious
> when
> >>> developing large graphs.
> >>>
> >>>
> >>>
> >>> Once processors have icons associated with them, several things become
> >>> much easier:
> >>>
> >>>
> >>>
> >>> 1.       The toolboxes are much easier to create, leveraging each
> >>> processors inherent icon representation
> >>>
> >>> 2.       The runtime view (current view) could simply have each
> >>> processor’s icon shown (either in the white space to left of “5 mins”
> or in
> >>> the border area)
> >>>
> >>> 3.       If a purely iconic view were added at some future point, then
> a
> >>> clear “as built” drawing of the data flow would make the graphs even
> more
> >>> self-documenting and obvious
> >>>
> >>>
> >>>
> >>> Lastly, when the generic processor is dragged onto the canvass (as it
> is
> >>> today), and a processor type is selected, it would be very easy to
> proceed
> >>> next to the Property dialog (if there are any mandatory properties
> that must
> >>> be configured before first use), reducing the number of clicks
> required to
> >>> get a processor up and running.
> >>>
> >>>
> >>>
> >>> I believe a usability study with target users would likely reveal the
> >>> above (or similar) conclusions.  In order for Nifi to scale with
> dozens or
> >>> even hundreds more processors, it’s clear that something has to give,
> as the
> >>> current method of choosing processor type has about run its course
> from a
> >>> usability standpoint IMHO.
> >>>
> >>>
> >>>
> >>> Hope that’s helpful.
> >>>
> >>>
> >>>
> >>> Rick
> >>>
> >>>
> >>
> >>
> > --
> > Rob
>

Mime
View raw message