nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Blue <>
Subject Re: [DISCUSS] Feature proposal: Read-only mode as default
Date Mon, 10 Aug 2015 20:02:35 GMT
If we're talking about read-only mode as a way to avoid moving 
processors when moving around on the graph, what about implementing 
something slightly different? What about having a toggle between 
drag-to-scroll and drag-to-move? Then users could keep the toggle in 
drag-to-scroll most of the time (and undo would put things back when the 
inevitable accident happens).

Then deletes would be handled by more sophisticated rules, like not 
deleting processors that are off the screen without confirmation.


On 08/10/2015 12:58 PM, Dan Bress wrote:
> +1 to exactly what Mark described in his last email for a system wide preference.
> Although I'm curious how you leave read-only mode and get into edit mode?  And how do
you leave edit mode and go back to read-only mode?
> On one hand, if I do not intend to edit the graph and I accidentally move a processor
I probably don't want it to prompt me "do you want to enter edit mode?"
> -In read-only mode, I think it would be a nice user experience to click anywhere on the
graph(including on a processor) and it moves the entire graph.
> On the other hand, if I right click a processor and hit configure I'd like to leave read-only
mode and go into edit mode.  I'm not sure I'd even want to be prompted with "do you want to
enter edit mode?" here since I obviously do.
> Dan Bress
> Software Engineer
> ONYX Consulting Services
> ________________________________________
> From: Mark Payne <>
> Sent: Monday, August 10, 2015 3:43 PM
> To:
> Subject: RE: [DISCUSS] Feature proposal: Read-only mode as default
> I'm definitely a +1. I accidentally drag processors all the time when I'm panning around
a large graph.
> I can understand how someone would get annoyed with this, though, and I can also appreciate
the desire
> to not start storing user preferences. However, I think we should probably at least supply
a system-level
> configuration for whether or not to have "read-only" the default mode. Then administrators
can turn it on
> or off, depending on the users of the system.
> ----------------------------------------
>> Date: Sat, 8 Aug 2015 20:50:07 -0400
>> Subject: Re: [DISCUSS] Feature proposal: Read-only mode as default
>> From:
>> To:
>> Thinking about it some more, I don't mind the concept of "read only"
>> toggle. Maybe it's not set by default, but it could be a really easy UI
>> element to add somewhere. Just a little slider-toggle element. [1]
>> In theory, this might be a UI only feature, it wouldn't strictly need
>> support in the backend api (just guessing). The logic is seemingly already
>> there, similar user experience as non-DFMs.
>> Anyway, +1 to the concept of read-only toggle mode. -1 for making it
>> default, but the user interface element should be easy to work either way.
>> Also agree that undo support might be free if versioning is added.
>> [1]
>> On Sat, Aug 8, 2015 at 3:05 PM, Joe Witt <> wrote:
>>> Ryan - the other useful case for read-only is basically when is
>>> scanning around the graph and accidentally moves a processor or
>>> relationship. By no means a big deal. The idea here was to make it
>>> explicit though that the user wishes to go into an edit mode.
>>> I do think the undo mechanism plays well and you're right that we can
>>> just focus on tightening up the delete case.
>>> Sounds like the prevailing view is to avoid read-only as a mode but
>>> rather to make it more explicit whenever we delete - and potentially
>>> move we could make more specific rather than simply them having
>>> clicked and dragged which is ambiguous with the process of panning.
>>> On Sat, Aug 8, 2015 at 2:57 PM, Ryan Blue <> wrote:
>>>> I'm not a big fan of having a read-only mode by default. It sounds like
>>>> something that would be frustrating for users when they try to make
>>> changes
>>>> and then have to figure out how to switch modes.
>>>> I think a clearer picture of the problem we're trying to solve would
>>> help my
>>>> understanding. I'm primarily thinking of the delete case you mentioned
>>> with
>>>> these comments...
>>>> If we're talking about accidentally deleting processors, then the current
>>>> mechanisms (IIRC) work pretty well: not deleting a running processor, one
>>>> that has live incoming connections, etc. If those rules are
>>> insufficient, I
>>>> would explore extending them rather than having a global read-only mode.
>>>> For the case where the wrong processor is selected because it is off the
>>>> screen, maybe having the confirmation pop up if anything affected wasn't
>>>> displayed to confirm? That way we don't have confirmations all the time
>>> but
>>>> still don't do unexpected things.
>>>> I really like the idea of "undo" as well. If that is limited to
>>> processors
>>>> that weren't running (because you can't delete ones that are), then that
>>>> makes the undo operation easier to implement.
>>>> rb
>>>> On 08/08/2015 11:31 AM, Joe Witt wrote:
>>>>> I can dig the user pref aspect but it would mean we start storing user
>>>>> prefs which is a bummer.
>>>>> On Aug 8, 2015 1:42 PM, "Tony Kurc" <> wrote:
>>>>>> Personally not a fan of the idea. Maybe something analogous to
>>> something
>>>>>> like 'lock the taskbar' in Windows that can have a system default
>>> setting
>>>>>> and a user preference of on or off.
>>>>>> On Sat, Aug 8, 2015 at 11:44 AM, johny casanova <
>>>>>> wrote:
>>>>>>> I agree it is easy to move it delete something by mistake. Some
>>>>>>> are
>>>>>>> huge or are using,more resources and are slower to load and you
>>>>>>> accidently do something by mistake. I believe the "are yous sure
>>> want
>>>>>> to
>>>>>>> delete?" its a good start.
>>>>>>> On Aug 7, 2015 10:31 PM, "Joe Witt" <>
>>>>>>>> Team,
>>>>>>>> We've been hearing from users of nifi that it is too easy
>>>>>>>> accidentally move something on the flow or delete large portions
>>>>>>>> the flow. This is the case when panning the screen for example
>>>>>>>> accidentally having a processor selected instead.
>>>>>>>> What is worth consideration then is the notion of making
the flow
>>>>>>>> 'read-only' by default. In this case the user would need
>>>>>>>> explicitly 'enable edit mode'. We would then also support
>>>>>>>> confirmation dialog or similar construct whenever deleting
>>>>>>>> on the flow.
>>>>>>>> Anyone have a strong objection to this concept? If so, do
you have
>>> an
>>>>>>>> alternative in mind that would help avoid accidental movement?
>>>>>>>> Thanks
>>>>>>>> Joe
>>>> --
>>>> Ryan Blue
>>>> Software Engineer
>>>> Cloudera, Inc.

Ryan Blue
Software Engineer
Cloudera, Inc.

View raw message