nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Bress <>
Subject Re: [DISCUSS] Feature proposal: Read-only mode as default
Date Mon, 10 Aug 2015 19:58:33 GMT
+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
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 flows
>>>>>> are
>>>>>> huge or are using,more resources and are slower to load and you can
>>>>>> 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" <> wrote:
>>>>>>> Team,
>>>>>>> We've been hearing from users of nifi that it is too easy to
>>>>>>> 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
>>>>>>> 'read-only' by default. In this case the user would need to
>>>>>>> explicitly 'enable edit mode'. We would then also support a
>>>>>>> confirmation dialog or similar construct whenever deleting components
>>>>>>> on the flow.
>>>>>>> Anyone have a strong objection to this concept? If so, do you
>> an
>>>>>>> alternative in mind that would help avoid accidental movement?
>>>>>>> Thanks
>>>>>>> Joe
>>> --
>>> Ryan Blue
>>> Software Engineer
>>> Cloudera, Inc.

View raw message