+1 to adding capabilities that will allow users to build the desired layout
more efficiently. Allowing them to more easily align components,
snap-to-grid, lock, and bend connections would all fall into this category.

I'm a little indifferent to supporting an auto-layout feature. I've tried a
number of different options for creating an optimum layout of directed
graphs and the results are typically sub-par for this purpose. Some of the
layouts being described are very useful when analyzing a dataset and
learning about the relationships between the elements. However, I'm not
sure how applicable they would be for visualizing a data flow. Building a
simple top-down left-right auto layout for a cyclic graph would also yield
poor results in my opinion. Additionally, supporting a view that is not
representative of the underlying flow.xml is a departure from our current
design model.

In short, my preference would be to provide the tools for the users to
build the layout they want rather than provide auto layouts that may not be
helpful.

Matt

On Tue, Jan 19, 2016 at 4:46 PM, Matt Burgess <mattyb...@gmail.com> wrote:

> +1 for "snap to grid" feature
>
> Sent from my iPhone
>
> > On Jan 19, 2016, at 4:20 PM, dan bress <danbr...@gmail.com> wrote:
> >
> > Maybe not exactly "auto-layout" but I would back a notion of having the
> > components snap to a coarser grain grid than what we currently have.
> > Sometimes I care a lot about having everything line up in the graph
> > horizontally and vertically, and it always takes a long time to achieve
> > this.
> >
> > I could see this being achieved by snapping the component to the same
> spot
> > horizontally as the component above it when you move it underneath
> another
> > component.  Or some magical "auto snap" button that does its best to
> align
> > everything with its nearest neighbors.
> >
> >> On Tue, Jan 19, 2016 at 12:37 PM Ryan H <rhendrickson.w...@gmail.com>
> wrote:
> >>
> >> I like your idea Rob, that would help with lining up relationships too
> >> (straight lines).
> >>
> >> On Matt's note, I don't think there should be a "standard" either,
> although
> >> best practices are always out there.
> >>
> >> On Matt's note of putting failures up above processes, we do that too.
> >> Totally depends on who made the flow first.  Sometimes, people don't
> even
> >> follow a convention in the same flow.xml file.
> >>
> >> For these reasons, I'd recommend alternate views to the flow.
> >>
> >> We have a couple projects that just allow you to rearrange a node-based
> >> graph, based on your preference, hierarchy, circular, pyramid, etc.
> >>
> >> Applying this to NiFi, having a couple different default auto-layout
> >> options that you can swap your current view to, but NOT change the
> original
> >> flow, would be nice.
> >>
> >> It would let you walk into someone else's, potentially large, dataflow
> and
> >> have a familiar way to view the flow.
> >>
> >> Ryan
> >>
> >>
> >>> On Tue, Jan 19, 2016 at 2:03 PM, Rob Moran <rmo...@gmail.com> wrote:
> >>>
> >>> I agree with Matt's points. I was just replying with something similar
> >>> basically saying I think trying to set a standard would not be
> >>> well-received.
> >>>
> >>> I believe what could be more useful are layout tools that would help
> >> users
> >>> place components to help achieve their preferred layouts. For example,
> >> the
> >>> ability to align (left, right, center) components
> >>> or horizontally/vertically distribute components evenly. Other features
> >>> such as snap-to and/or smart-guides could make it easier for users to
> >>> follow their organization's best practices when designing a flow.
> >>>
> >>> Rob
> >>>
> >>> On Tue, Jan 19, 2016 at 1:49 PM, Matthew Clarke <
> >> matt.clarke....@gmail.com
> >>> wrote:
> >>>
> >>>> Ryan,
> >>>>
> >>>>          Setting a standard is a difficult thing to do.  The
> >> complexity
> >>>> that can exist in many flows would make enforcing a standard
> difficult.
> >>> The
> >>>> first example you provide of success to points right while failures
> >> point
> >>>> up is not recommended. It would be better to have failures point down
> >>> since
> >>>> it is common to put labels over processor(s). Any relationships
> >> pointing
> >>> up
> >>>> would pass through these labels making both the relationship box and
> >> the
> >>>> label hard to read.  It is often coomon to see flows designed with a
> >>>> combination of left to right and top to bottom design.
> >>>>
> >>>> Matt
> >>>>
> >>>> On Tue, Jan 19, 2016 at 12:07 PM, Ryan H <rhendrickson.w...@gmail.com
> >
> >>>> wrote:
> >>>>
> >>>>> Hi Rob,
> >>>>>    Yea we did, it was at the end of the meeting.
> >>>>>
> >>>>>    I think it would be useful to have a couple default type views
> >> that
> >>>>> help standardize flow layout across the community.
> >>>>>
> >>>>>    For example, when we organize processors left-to-right, failure
> >>>>> relationships always point up, and success always point right.
> >>>>>    Alternatively, when we organize processors up-and-down, failure
> >>>>> relationships always point left, and successes always point down.
> >>>>>
> >>>>>    Of course, in some of these scenarios there are processors that
> >>> have
> >>>>> more than 1 success relationship, but that's when a good layout
> >> library
> >>>>> would come into play.
> >>>>>
> >>>>>    What do you think?
> >>>>>
> >>>>> On Tue, Jan 19, 2016 at 11:10 AM, Rob Moran <rmo...@gmail.com>
> >> wrote:
> >>>>>
> >>>>>> Ryan - I think we spoke briefly (at a very high level) about this
> >> at
> >>> a
> >>>>>> prior meetup. What alternate views did you have in mind, and in
> >> what
> >>>> ways
> >>>>>> do you think they'd be useful?
> >>>>>>
> >>>>>> Rob
> >>>>>>
> >>>>>> On Tue, Jan 19, 2016 at 10:56 AM, Ryan H <
> >>> rhendrickson.w...@gmail.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> It'd be pretty awesome if NiFi provided the ability to
> >>> auto-organize
> >>>> a
> >>>>>>> layout.
> >>>>>>>
> >>>>>>> Maybe even just a auto-organized layout that doesn't change the
> >>>>> flow.xml,
> >>>>>>> just an alternate view.
> >>>>>>>
> >>>>>>> Looking at these demos here: http://js.cytoscape.org/#demos
> >>>>>>>
> >>>>>>> Ryan
> >>
>

Reply via email to