Joe,
What I'm referring to as far as emphasizing "important" processors is that
there are many places in my workflow where I do a PutFile for logging purposes,
and I have one for success and a separate one for failure. So for many of my
main processors, there are two connectors to PutFiles. This makes the workflow
look very cluttered, and when doing a demo it is difficult to see the main path
that flowfiles are taking without explanation, when I'd like it to be
intuitive. In fact, there are some cases that I really want to add PutFiles for
logging but since it will make the workflow look so cluttered I don't do it.
Maybe this problem can be solved by an option to route all failures or even
successes from some or all processors to do a PutFile to a specific folder?
Maybe we can minimize some processor such as these PutFiles to a small icon
instead of the whole box to save screen space? I often don't care about
processor stats for these processors anyway, but maybe they'd be displayed on
mouse hover.
Furthermore, in some of my workflows I have my main tasks that deal with the
actual processing of the incoming data, and other "side tasks" that I do with
the data like collect special metrics, storing some metadata in a special
database, sending status emails, etc. I handle this now with Processor Groups,
and that helps, but I find it a bit unwieldy to create many processor groups
that only have two or three processors in them (and then the processor group
needs the input/output ports, further complicated an otherwise simple
workflow). There are also cases where for some failures, I have a ControlRate
processor and then retry the flowfile after a certain period of time - this is
not a "main" part of the workflow, but it clutters it and it's not intuitive to
see what's happening. I think I'd like to solve this problem by just being able
to align selected processors that I consider more important, and having the
others off to a side.
As far as accidentally dragging processors is concerned, sometimes I intend to
the pan screen and end up moving a processor or moving a label that I used to
highlight a section of my flow. For demos, it would be nice to lock the entire
page layout. Maybe this can be accomplished with a button on the top right
corner to enable/disable layout changes or disable adding new processors, and
only allow viewing processor properties - a sort of "read only" mode.
Thanks for taking my feedback into consideration. I still find Nifi incredibly
useful for handling my complicated workflows and appreciate your work in
developing it!
-Elli
On Tuesday, January 19, 2016 5:03 PM, Joe Witt <joe.w...@gmail.com> wrote:
Elli
"it is sometimes too easy to mis-align processors by dragging them accidentally"
Great point I must admit I too do that. Often in really important
demos. I've gotten good at making jokes about it. Probably should
have gotten good at submitting a JIRA :-)
I'd like to understand more about your other idea for emphasizing
processors which are more important. I can understand the idea I
think but I'm worried about how we could make the user experience
worth the effort for the person signaling the emphasis to be of use
for the people consuming that detail.
Thanks
Joe
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
>>>
