You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nifi.apache.org by Joe Witt <jo...@gmail.com> on 2015/08/08 04:31:05 UTC
[DISCUSS] Feature proposal: Read-only mode as default
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 of
the flow. This is the case when panning the screen for example and
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 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 have an
alternative in mind that would help avoid accidental movement?
Thanks
Joe
Re: [DISCUSS] Feature proposal: Read-only mode as default
Posted by Corey Flowers <cf...@onyxpoint.com>.
Well there is always the cya "are you sure you want to delete" idiot
pop up button.
For the actual undo, you could do something similar to copy and
"stack" it. I am not sure what mechanism is used for the copy but the
undo could work in the same way. Also, would it only undo elements on
the graph or property and state changes?
Sent from my iPhone
> On Aug 8, 2015, at 12:01 AM, Joe Witt <jo...@gmail.com> wrote:
>
> The motive here is prevention from unintended modification.
>
> Undo, as part of a larger versioning effort, is a good step as well.
>
>> On Fri, Aug 7, 2015 at 11:44 PM, Adam Taft <ad...@adamtaft.com> wrote:
>> Alternative suggestion: undo
>>
>> It shouldn't be too hard to keep multiple diffs of the flow.xml around to
>> allow for some sort of undo capabilities. What are the thoughts or
>> concerns for supporting undo?
>>
>>> On Fri, Aug 7, 2015 at 10:31 PM, Joe Witt <jo...@gmail.com> 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 of
>>> the flow. This is the case when panning the screen for example and
>>> 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 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 have an
>>> alternative in mind that would help avoid accidental movement?
>>>
>>> Thanks
>>> Joe
>>>
Re: [DISCUSS] Feature proposal: Read-only mode as default
Posted by Joe Witt <jo...@gmail.com>.
The motive here is prevention from unintended modification.
Undo, as part of a larger versioning effort, is a good step as well.
On Fri, Aug 7, 2015 at 11:44 PM, Adam Taft <ad...@adamtaft.com> wrote:
> Alternative suggestion: undo
>
> It shouldn't be too hard to keep multiple diffs of the flow.xml around to
> allow for some sort of undo capabilities. What are the thoughts or
> concerns for supporting undo?
>
> On Fri, Aug 7, 2015 at 10:31 PM, Joe Witt <jo...@gmail.com> 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 of
>> the flow. This is the case when panning the screen for example and
>> 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 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 have an
>> alternative in mind that would help avoid accidental movement?
>>
>> Thanks
>> Joe
>>
Re: [DISCUSS] Feature proposal: Read-only mode as default
Posted by Adam Taft <ad...@adamtaft.com>.
Alternative suggestion: undo
It shouldn't be too hard to keep multiple diffs of the flow.xml around to
allow for some sort of undo capabilities. What are the thoughts or
concerns for supporting undo?
On Fri, Aug 7, 2015 at 10:31 PM, Joe Witt <jo...@gmail.com> 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 of
> the flow. This is the case when panning the screen for example and
> 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 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 have an
> alternative in mind that would help avoid accidental movement?
>
> Thanks
> Joe
>
RE: [DISCUSS] Feature proposal: Read-only mode as default
Posted by Mark Payne <ma...@hotmail.com>.
Accidentally moving processors is the main reason that I like this idea. However, I would like to see it
truly in read-only mode. If I go to Configure a processor, I may still not want to edit the processor.
I may just want to view the configuration and I'd like to ensure that I don't accidentally change (or delete)
something.
----------------------------------------
> Date: Mon, 10 Aug 2015 13:02:35 -0700
> From: blue@cloudera.com
> To: dev@nifi.apache.org
> Subject: Re: [DISCUSS] Feature proposal: Read-only mode as default
>
> 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.
>
> rb
>
> 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 <ma...@hotmail.com>
>> Sent: Monday, August 10, 2015 3:43 PM
>> To: dev@nifi.apache.org
>> 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: adam@adamtaft.com
>>> To: dev@nifi.apache.org
>>>
>>> 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] http://turbo.premiumpixels.com/wp-content/uploads/2011/04/preview2.jpg
>>>
>>>
>>>
>>>
>>> On Sat, Aug 8, 2015 at 3:05 PM, Joe Witt <jo...@gmail.com> 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 <bl...@cloudera.com> 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" <tr...@gmail.com> 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 <
>>>>>>> computertech2124@gmail.com>
>>>>>>> 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 u
>>>> want
>>>>>>>
>>>>>>> to
>>>>>>>>
>>>>>>>> delete?" its a good start.
>>>>>>>> On Aug 7, 2015 10:31 PM, "Joe Witt" <jo...@gmail.com> 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 of
>>>>>>>>> the flow. This is the case when panning the screen for example and
>>>>>>>>> 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 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 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.
Re: [DISCUSS] Feature proposal: Read-only mode as default
Posted by Ryan Blue <bl...@cloudera.com>.
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.
rb
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 <ma...@hotmail.com>
> Sent: Monday, August 10, 2015 3:43 PM
> To: dev@nifi.apache.org
> 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: adam@adamtaft.com
>> To: dev@nifi.apache.org
>>
>> 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] http://turbo.premiumpixels.com/wp-content/uploads/2011/04/preview2.jpg
>>
>>
>>
>>
>> On Sat, Aug 8, 2015 at 3:05 PM, Joe Witt <jo...@gmail.com> 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 <bl...@cloudera.com> 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" <tr...@gmail.com> 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 <
>>>>>> computertech2124@gmail.com>
>>>>>> 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 u
>>> want
>>>>>>
>>>>>> to
>>>>>>>
>>>>>>> delete?" its a good start.
>>>>>>> On Aug 7, 2015 10:31 PM, "Joe Witt" <jo...@gmail.com> 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 of
>>>>>>>> the flow. This is the case when panning the screen for example and
>>>>>>>> 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 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 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.
Re: [DISCUSS] Feature proposal: Read-only mode as default
Posted by Dan Bress <db...@onyxconsults.com>.
+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 <ma...@hotmail.com>
Sent: Monday, August 10, 2015 3:43 PM
To: dev@nifi.apache.org
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: adam@adamtaft.com
> To: dev@nifi.apache.org
>
> 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] http://turbo.premiumpixels.com/wp-content/uploads/2011/04/preview2.jpg
>
>
>
>
> On Sat, Aug 8, 2015 at 3:05 PM, Joe Witt <jo...@gmail.com> 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 <bl...@cloudera.com> 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" <tr...@gmail.com> 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 <
>>>>> computertech2124@gmail.com>
>>>>> 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 u
>> want
>>>>>
>>>>> to
>>>>>>
>>>>>> delete?" its a good start.
>>>>>> On Aug 7, 2015 10:31 PM, "Joe Witt" <jo...@gmail.com> 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 of
>>>>>>> the flow. This is the case when panning the screen for example and
>>>>>>> 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 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 have
>> an
>>>>>>> alternative in mind that would help avoid accidental movement?
>>>>>>>
>>>>>>> Thanks
>>>>>>> Joe
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Ryan Blue
>>> Software Engineer
>>> Cloudera, Inc.
>>
Re: [DISCUSS] Feature proposal: Read-only mode as default
Posted by Rob Moran <rm...@gmail.com>.
Here's my .02:
Regarding read-only, if that is all that's implemented, the user still
faces the challenge of unintended changes once they engage edit mode.
Already mentioned but of personal preference, the 'undo' action. Pair undo
with a notification of the change that was made, think like Gmail or Inbox.
To expand on this further, introduce a history feature with the ability to
revert back to past states (in case something goes unnoticed).
I also see usefulness in confirmation dialogs in combination with
notification/undo functionality, reserved for extreme cases where
significant change would occur.
Another idea to consider is explicit tools. By default the cursor could be
a move or grab icon that only lets the user navigate the graph. They could
click anywhere, on anything to navigate. Then, an explicit action to choose
a 'selection' tool that will enable them to click on and select an item for
follow-on action. Keyboard shortcuts could be introduced allowing advanced
users to quickly shift between tools.
On Mon, Aug 10, 2015 at 6:00 PM johny casanova <co...@gmail.com>
wrote:
> I agree I think Mark explained it right on the money what I was trying to
> say before.
> On Aug 10, 2015 3:44 PM, "Mark Payne" <ma...@hotmail.com> wrote:
>
> > 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: adam@adamtaft.com
> > > To: dev@nifi.apache.org
> > >
> > > 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]
> > http://turbo.premiumpixels.com/wp-content/uploads/2011/04/preview2.jpg
> > >
> > >
> > >
> > >
> > > On Sat, Aug 8, 2015 at 3:05 PM, Joe Witt <jo...@gmail.com> 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 <bl...@cloudera.com> 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" <tr...@gmail.com> 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 <
> > >>>>> computertech2124@gmail.com>
> > >>>>> 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 u
> > >> want
> > >>>>>
> > >>>>> to
> > >>>>>>
> > >>>>>> delete?" its a good start.
> > >>>>>> On Aug 7, 2015 10:31 PM, "Joe Witt" <jo...@gmail.com> 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
> of
> > >>>>>>> the flow. This is the case when panning the screen for example
> and
> > >>>>>>> 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 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
> have
> > >> an
> > >>>>>>> alternative in mind that would help avoid accidental movement?
> > >>>>>>>
> > >>>>>>> Thanks
> > >>>>>>> Joe
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>>
> > >>> --
> > >>> Ryan Blue
> > >>> Software Engineer
> > >>> Cloudera, Inc.
> > >>
> >
>
--
Rob
RE: [DISCUSS] Feature proposal: Read-only mode as default
Posted by johny casanova <co...@gmail.com>.
I agree I think Mark explained it right on the money what I was trying to
say before.
On Aug 10, 2015 3:44 PM, "Mark Payne" <ma...@hotmail.com> wrote:
> 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: adam@adamtaft.com
> > To: dev@nifi.apache.org
> >
> > 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]
> http://turbo.premiumpixels.com/wp-content/uploads/2011/04/preview2.jpg
> >
> >
> >
> >
> > On Sat, Aug 8, 2015 at 3:05 PM, Joe Witt <jo...@gmail.com> 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 <bl...@cloudera.com> 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" <tr...@gmail.com> 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 <
> >>>>> computertech2124@gmail.com>
> >>>>> 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 u
> >> want
> >>>>>
> >>>>> to
> >>>>>>
> >>>>>> delete?" its a good start.
> >>>>>> On Aug 7, 2015 10:31 PM, "Joe Witt" <jo...@gmail.com> 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 of
> >>>>>>> the flow. This is the case when panning the screen for example and
> >>>>>>> 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 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 have
> >> an
> >>>>>>> alternative in mind that would help avoid accidental movement?
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>> Joe
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Ryan Blue
> >>> Software Engineer
> >>> Cloudera, Inc.
> >>
>
RE: [DISCUSS] Feature proposal: Read-only mode as default
Posted by Mark Payne <ma...@hotmail.com>.
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: adam@adamtaft.com
> To: dev@nifi.apache.org
>
> 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] http://turbo.premiumpixels.com/wp-content/uploads/2011/04/preview2.jpg
>
>
>
>
> On Sat, Aug 8, 2015 at 3:05 PM, Joe Witt <jo...@gmail.com> 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 <bl...@cloudera.com> 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" <tr...@gmail.com> 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 <
>>>>> computertech2124@gmail.com>
>>>>> 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 u
>> want
>>>>>
>>>>> to
>>>>>>
>>>>>> delete?" its a good start.
>>>>>> On Aug 7, 2015 10:31 PM, "Joe Witt" <jo...@gmail.com> 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 of
>>>>>>> the flow. This is the case when panning the screen for example and
>>>>>>> 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 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 have
>> an
>>>>>>> alternative in mind that would help avoid accidental movement?
>>>>>>>
>>>>>>> Thanks
>>>>>>> Joe
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Ryan Blue
>>> Software Engineer
>>> Cloudera, Inc.
>>
Re: [DISCUSS] Feature proposal: Read-only mode as default
Posted by Adam Taft <ad...@adamtaft.com>.
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] http://turbo.premiumpixels.com/wp-content/uploads/2011/04/preview2.jpg
On Sat, Aug 8, 2015 at 3:05 PM, Joe Witt <jo...@gmail.com> 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 <bl...@cloudera.com> 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" <tr...@gmail.com> 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 <
> >>> computertech2124@gmail.com>
> >>> 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 u
> want
> >>>
> >>> to
> >>>>
> >>>> delete?" its a good start.
> >>>> On Aug 7, 2015 10:31 PM, "Joe Witt" <jo...@gmail.com> 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 of
> >>>>> the flow. This is the case when panning the screen for example and
> >>>>> 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 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 have
> an
> >>>>> alternative in mind that would help avoid accidental movement?
> >>>>>
> >>>>> Thanks
> >>>>> Joe
> >>>>>
> >>>>
> >>>
> >>
> >
> >
> > --
> > Ryan Blue
> > Software Engineer
> > Cloudera, Inc.
>
Re: [DISCUSS] Feature proposal: Read-only mode as default
Posted by Joe Witt <jo...@gmail.com>.
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 <bl...@cloudera.com> 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" <tr...@gmail.com> 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 <
>>> computertech2124@gmail.com>
>>> 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 u want
>>>
>>> to
>>>>
>>>> delete?" its a good start.
>>>> On Aug 7, 2015 10:31 PM, "Joe Witt" <jo...@gmail.com> 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 of
>>>>> the flow. This is the case when panning the screen for example and
>>>>> 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 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 have an
>>>>> alternative in mind that would help avoid accidental movement?
>>>>>
>>>>> Thanks
>>>>> Joe
>>>>>
>>>>
>>>
>>
>
>
> --
> Ryan Blue
> Software Engineer
> Cloudera, Inc.
Re: [DISCUSS] Feature proposal: Read-only mode as default
Posted by Ryan Blue <bl...@cloudera.com>.
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" <tr...@gmail.com> 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 <
>> computertech2124@gmail.com>
>> 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 u want
>> to
>>> delete?" its a good start.
>>> On Aug 7, 2015 10:31 PM, "Joe Witt" <jo...@gmail.com> 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 of
>>>> the flow. This is the case when panning the screen for example and
>>>> 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 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 have an
>>>> alternative in mind that would help avoid accidental movement?
>>>>
>>>> Thanks
>>>> Joe
>>>>
>>>
>>
>
--
Ryan Blue
Software Engineer
Cloudera, Inc.
Re: [DISCUSS] Feature proposal: Read-only mode as default
Posted by Joe Witt <jo...@gmail.com>.
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" <tr...@gmail.com> 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 <
> computertech2124@gmail.com>
> 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 u want
> to
> > delete?" its a good start.
> > On Aug 7, 2015 10:31 PM, "Joe Witt" <jo...@gmail.com> 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 of
> > > the flow. This is the case when panning the screen for example and
> > > 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 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 have an
> > > alternative in mind that would help avoid accidental movement?
> > >
> > > Thanks
> > > Joe
> > >
> >
>
Re: [DISCUSS] Feature proposal: Read-only mode as default
Posted by Tony Kurc <tr...@gmail.com>.
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 <co...@gmail.com>
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 u want to
> delete?" its a good start.
> On Aug 7, 2015 10:31 PM, "Joe Witt" <jo...@gmail.com> 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 of
> > the flow. This is the case when panning the screen for example and
> > 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 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 have an
> > alternative in mind that would help avoid accidental movement?
> >
> > Thanks
> > Joe
> >
>
Re: [DISCUSS] Feature proposal: Read-only mode as default
Posted by johny casanova <co...@gmail.com>.
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 u want to
delete?" its a good start.
On Aug 7, 2015 10:31 PM, "Joe Witt" <jo...@gmail.com> 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 of
> the flow. This is the case when panning the screen for example and
> 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 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 have an
> alternative in mind that would help avoid accidental movement?
>
> Thanks
> Joe
>
Re: [DISCUSS] Feature proposal: Read-only mode as default
Posted by Brandon DeVries <br...@jhu.edu>.
I think "undo" is the most important part here. I agree with Alex's
statement, "accidents happen; I prefer to enable users to learn from
mistakes and exercise more care next time." Delete confirmations may be
fine (although I suspect they would begin to annoy me fairly quickly... if
it's just for things not visible on the graph its probably fine), and
reducing accidental movement is all well and good. But ultimately, if i
can say "whoops, undo" then they don't really matter. And as a side
effect, maybe I'll be more careful next time. Also, who says I'll remember
that I left the graph in "edit" mode? If I get pulled to something else
and come back, and have been trained that "read only" is default, then I
run the risk of being bitten by the same things "edit" vs. "read only" was
supposed to prevent. I would suggest focusing on implementing "undo",
getting that in people's hands, and then seeing if after having done that
anyone still cares about the other issues .
Brandon
On Tue, Aug 11, 2015 at 8:28 AM, Joe Witt <jo...@gmail.com> wrote:
> To summarize where we're at ...
>
> Proposed approaches (summary):
>
> - Establish a default read-only view whereby an operator can enable
> edit mode. Use confirmation dialogs for deletes.
>
> - Keep the current model but add support for ‘undo’.
>
> - Let the user choose whether to lock their view or not as user preference.
>
> - For delete add more protections to make accidents less likely and
> for movement provide an explicit ‘move action’.
>
> The idea of locking seems to have some strong views on both sides and
> both sides have even been argued by the same people (i now count
> myself among that group).
>
> It looks like a consensus view there though is:
>
> - Try to make panning the view of the flow and moving components on
> the flow two specific/discrete actions to avoid accidental movement.
>
> - Add support for undo
>
> - Provide sufficient dialog/protection for delete cases.
>
> This preserves the model whereby we generally trust that the user will
> do the right thing and we’ll do more to help them and that when they
> don’t they will learn and have help to promptly restore a good state.
> How do folks feel about that?
>
> Thanks
> Joe
>
> On Tue, Aug 11, 2015 at 5:11 AM, Alex Moundalexis <al...@cloudera.com>
> wrote:
> > Counterpoint, accidents happen; I prefer to enable users to learn from
> > mistakes and exercise more care next time. You can't remove every mildly
> > sharp edge without impacting experienced operators; resist the urge at a
> few
> > comments to dumb down the tool.
> >
> > If some protection is added to the UI, suggest an option for "expert
> mode"
> > that retains original functionality... that way experienced operators
> aren't
> > affected.
> >
> > Alex Moundalexis
> > Senior Solutions Architect
> > Cloudera Partner Engineering
> >
> > Sent from a mobile device; please excuse brevity.
> >
> > On Aug 7, 2015 10:31 PM, "Joe Witt" <jo...@gmail.com> 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 of
> >> the flow. This is the case when panning the screen for example and
> >> 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 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 have an
> >> alternative in mind that would help avoid accidental movement?
> >>
> >> Thanks
> >> Joe
>
Re: [DISCUSS] Feature proposal: Read-only mode as default
Posted by Joe Witt <jo...@gmail.com>.
Ok all the thread has died down and reading where there is a strong
consensus the main thing that comes out the other end here is the
desire for 'undo'. I believe this is well captured in [1].
Other ideas where presented here that are also interesting and perhaps
once we get make progress on the other more clarity will occur on
those. Great discussion all - thanks!
Joe
[1] https://cwiki.apache.org/confluence/display/NIFI/Configuration+Management+of+Flows
On Fri, Aug 14, 2015 at 8:13 AM, Joe Skora <js...@gmail.com> wrote:
> +1 for read-only as a toggle with a system property to configure the
> default.
>
> +1 (+2 +3) for Undo. Undo is a common and expected application feature
> even in web UIs that eliminates a lot of pain and anxiety. But Undo is
> complicated, especially in a web UI, so perhaps it could be phased-in? I
> see a lot of value in even one level of undo, like GMAIL, so that might be
> a good target for a first phase. That could eventually be expanded to
> multiple levels with less pressure and more time to get it right.
>
> On Tue, Aug 11, 2015 at 12:22 PM, Ryan Blue <bl...@cloudera.com> wrote:
>
>> +1 for the consensus view as Joe summarized it.
>>
>> I also agree with only using confirmations sparingly.
>>
>> rb
>>
>>
>> On 08/11/2015 07:07 AM, Ricky Saltzer wrote:
>>
>>> +1 for read-only by default. It would be nice to have some easy way to
>>> tell
>>> if you're in edit/view mode, perhaps the canvas be black/white during view
>>> and color during edit? or, something along those lines.
>>>
>>> On Tue, Aug 11, 2015 at 9:57 AM, Michael Moser <mo...@gmail.com>
>>> wrote:
>>>
>>> "undo" seems to be the stretch goal that I think that would solve most
>>>> concerns of unintended modifications to a graph. +1
>>>>
>>>> Meanwhile, I'd like to caution against confirmation dialogs. Extra
>>>> clicks
>>>> quickly annoy users while they work. I suggest no dialog when deleting a
>>>> single queue or processor, or when moving 'objects' around. Perhaps
>>>> bring
>>>> a confirmation dialog into play only when deleting more than 1 'object'.
>>>>
>>>> Personally I really like the idea of a read-only mode toggle, even if it
>>>> was not persisted as a user preference and was only remembered during the
>>>> current browser 'session'.
>>>>
>>>> -- Mike
>>>>
>>>> On Tue, Aug 11, 2015 at 9:11 AM, Rob Moran <rm...@gmail.com> wrote:
>>>>
>>>> The consensus view looks good to me. I believe preserving the current
>>>>>
>>>> model
>>>>
>>>>> as Joe describes it is a smart approach.
>>>>>
>>>>> An undo action and restrained use of confirmation dialogs are minimal
>>>>> and
>>>>> should not significantly impede experienced operators. More often than
>>>>>
>>>> not,
>>>>
>>>>> I'd bet a user would expect similar functionality.
>>>>>
>>>>> As is evident by the views expressed around read-only/locking, it will
>>>>> be
>>>>> very difficult to please a majority of users with different user modes
>>>>>
>>>> and
>>>>
>>>>> UI states.
>>>>>
>>>>> On Tue, Aug 11, 2015 at 8:29 AM Joe Witt <jo...@gmail.com> wrote:
>>>>>
>>>>> To summarize where we're at ...
>>>>>>
>>>>>> Proposed approaches (summary):
>>>>>>
>>>>>> - Establish a default read-only view whereby an operator can enable
>>>>>> edit mode. Use confirmation dialogs for deletes.
>>>>>>
>>>>>> - Keep the current model but add support for ‘undo’.
>>>>>>
>>>>>> - Let the user choose whether to lock their view or not as user
>>>>>>
>>>>> preference.
>>>>>
>>>>>>
>>>>>> - For delete add more protections to make accidents less likely and
>>>>>> for movement provide an explicit ‘move action’.
>>>>>>
>>>>>> The idea of locking seems to have some strong views on both sides and
>>>>>> both sides have even been argued by the same people (i now count
>>>>>> myself among that group).
>>>>>>
>>>>>> It looks like a consensus view there though is:
>>>>>>
>>>>>> - Try to make panning the view of the flow and moving components on
>>>>>> the flow two specific/discrete actions to avoid accidental movement.
>>>>>>
>>>>>> - Add support for undo
>>>>>>
>>>>>> - Provide sufficient dialog/protection for delete cases.
>>>>>>
>>>>>> This preserves the model whereby we generally trust that the user will
>>>>>> do the right thing and we’ll do more to help them and that when they
>>>>>> don’t they will learn and have help to promptly restore a good state.
>>>>>> How do folks feel about that?
>>>>>>
>>>>>> Thanks
>>>>>> Joe
>>>>>>
>>>>>> On Tue, Aug 11, 2015 at 5:11 AM, Alex Moundalexis <al...@cloudera.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Counterpoint, accidents happen; I prefer to enable users to learn
>>>>>>>
>>>>>> from
>>>>
>>>>> mistakes and exercise more care next time. You can't remove every
>>>>>>>
>>>>>> mildly
>>>>>
>>>>>> sharp edge without impacting experienced operators; resist the urge
>>>>>>>
>>>>>> at
>>>>
>>>>> a
>>>>>
>>>>>> few
>>>>>>
>>>>>>> comments to dumb down the tool.
>>>>>>>
>>>>>>> If some protection is added to the UI, suggest an option for "expert
>>>>>>>
>>>>>> mode"
>>>>>>
>>>>>>> that retains original functionality... that way experienced operators
>>>>>>>
>>>>>> aren't
>>>>>>
>>>>>>> affected.
>>>>>>>
>>>>>>> Alex Moundalexis
>>>>>>> Senior Solutions Architect
>>>>>>> Cloudera Partner Engineering
>>>>>>>
>>>>>>> Sent from a mobile device; please excuse brevity.
>>>>>>>
>>>>>>> On Aug 7, 2015 10:31 PM, "Joe Witt" <jo...@gmail.com> 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 of
>>>>>>>> the flow. This is the case when panning the screen for example and
>>>>>>>> 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 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 have
>>>>>>>>
>>>>>>> an
>>>>
>>>>> alternative in mind that would help avoid accidental movement?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Joe
>>>>>>>>
>>>>>>>
>>>>>> --
>>>>> Rob
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>> --
>> Ryan Blue
>> Software Engineer
>> Cloudera, Inc.
>>
Re: [DISCUSS] Feature proposal: Read-only mode as default
Posted by Joe Skora <js...@gmail.com>.
+1 for read-only as a toggle with a system property to configure the
default.
+1 (+2 +3) for Undo. Undo is a common and expected application feature
even in web UIs that eliminates a lot of pain and anxiety. But Undo is
complicated, especially in a web UI, so perhaps it could be phased-in? I
see a lot of value in even one level of undo, like GMAIL, so that might be
a good target for a first phase. That could eventually be expanded to
multiple levels with less pressure and more time to get it right.
On Tue, Aug 11, 2015 at 12:22 PM, Ryan Blue <bl...@cloudera.com> wrote:
> +1 for the consensus view as Joe summarized it.
>
> I also agree with only using confirmations sparingly.
>
> rb
>
>
> On 08/11/2015 07:07 AM, Ricky Saltzer wrote:
>
>> +1 for read-only by default. It would be nice to have some easy way to
>> tell
>> if you're in edit/view mode, perhaps the canvas be black/white during view
>> and color during edit? or, something along those lines.
>>
>> On Tue, Aug 11, 2015 at 9:57 AM, Michael Moser <mo...@gmail.com>
>> wrote:
>>
>> "undo" seems to be the stretch goal that I think that would solve most
>>> concerns of unintended modifications to a graph. +1
>>>
>>> Meanwhile, I'd like to caution against confirmation dialogs. Extra
>>> clicks
>>> quickly annoy users while they work. I suggest no dialog when deleting a
>>> single queue or processor, or when moving 'objects' around. Perhaps
>>> bring
>>> a confirmation dialog into play only when deleting more than 1 'object'.
>>>
>>> Personally I really like the idea of a read-only mode toggle, even if it
>>> was not persisted as a user preference and was only remembered during the
>>> current browser 'session'.
>>>
>>> -- Mike
>>>
>>> On Tue, Aug 11, 2015 at 9:11 AM, Rob Moran <rm...@gmail.com> wrote:
>>>
>>> The consensus view looks good to me. I believe preserving the current
>>>>
>>> model
>>>
>>>> as Joe describes it is a smart approach.
>>>>
>>>> An undo action and restrained use of confirmation dialogs are minimal
>>>> and
>>>> should not significantly impede experienced operators. More often than
>>>>
>>> not,
>>>
>>>> I'd bet a user would expect similar functionality.
>>>>
>>>> As is evident by the views expressed around read-only/locking, it will
>>>> be
>>>> very difficult to please a majority of users with different user modes
>>>>
>>> and
>>>
>>>> UI states.
>>>>
>>>> On Tue, Aug 11, 2015 at 8:29 AM Joe Witt <jo...@gmail.com> wrote:
>>>>
>>>> To summarize where we're at ...
>>>>>
>>>>> Proposed approaches (summary):
>>>>>
>>>>> - Establish a default read-only view whereby an operator can enable
>>>>> edit mode. Use confirmation dialogs for deletes.
>>>>>
>>>>> - Keep the current model but add support for ‘undo’.
>>>>>
>>>>> - Let the user choose whether to lock their view or not as user
>>>>>
>>>> preference.
>>>>
>>>>>
>>>>> - For delete add more protections to make accidents less likely and
>>>>> for movement provide an explicit ‘move action’.
>>>>>
>>>>> The idea of locking seems to have some strong views on both sides and
>>>>> both sides have even been argued by the same people (i now count
>>>>> myself among that group).
>>>>>
>>>>> It looks like a consensus view there though is:
>>>>>
>>>>> - Try to make panning the view of the flow and moving components on
>>>>> the flow two specific/discrete actions to avoid accidental movement.
>>>>>
>>>>> - Add support for undo
>>>>>
>>>>> - Provide sufficient dialog/protection for delete cases.
>>>>>
>>>>> This preserves the model whereby we generally trust that the user will
>>>>> do the right thing and we’ll do more to help them and that when they
>>>>> don’t they will learn and have help to promptly restore a good state.
>>>>> How do folks feel about that?
>>>>>
>>>>> Thanks
>>>>> Joe
>>>>>
>>>>> On Tue, Aug 11, 2015 at 5:11 AM, Alex Moundalexis <al...@cloudera.com>
>>>>> wrote:
>>>>>
>>>>>> Counterpoint, accidents happen; I prefer to enable users to learn
>>>>>>
>>>>> from
>>>
>>>> mistakes and exercise more care next time. You can't remove every
>>>>>>
>>>>> mildly
>>>>
>>>>> sharp edge without impacting experienced operators; resist the urge
>>>>>>
>>>>> at
>>>
>>>> a
>>>>
>>>>> few
>>>>>
>>>>>> comments to dumb down the tool.
>>>>>>
>>>>>> If some protection is added to the UI, suggest an option for "expert
>>>>>>
>>>>> mode"
>>>>>
>>>>>> that retains original functionality... that way experienced operators
>>>>>>
>>>>> aren't
>>>>>
>>>>>> affected.
>>>>>>
>>>>>> Alex Moundalexis
>>>>>> Senior Solutions Architect
>>>>>> Cloudera Partner Engineering
>>>>>>
>>>>>> Sent from a mobile device; please excuse brevity.
>>>>>>
>>>>>> On Aug 7, 2015 10:31 PM, "Joe Witt" <jo...@gmail.com> 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 of
>>>>>>> the flow. This is the case when panning the screen for example and
>>>>>>> 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 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 have
>>>>>>>
>>>>>> an
>>>
>>>> alternative in mind that would help avoid accidental movement?
>>>>>>>
>>>>>>> Thanks
>>>>>>> Joe
>>>>>>>
>>>>>>
>>>>> --
>>>> Rob
>>>>
>>>>
>>>
>>
>>
>>
>
> --
> Ryan Blue
> Software Engineer
> Cloudera, Inc.
>
Re: [DISCUSS] Feature proposal: Read-only mode as default
Posted by Ryan Blue <bl...@cloudera.com>.
+1 for the consensus view as Joe summarized it.
I also agree with only using confirmations sparingly.
rb
On 08/11/2015 07:07 AM, Ricky Saltzer wrote:
> +1 for read-only by default. It would be nice to have some easy way to tell
> if you're in edit/view mode, perhaps the canvas be black/white during view
> and color during edit? or, something along those lines.
>
> On Tue, Aug 11, 2015 at 9:57 AM, Michael Moser <mo...@gmail.com> wrote:
>
>> "undo" seems to be the stretch goal that I think that would solve most
>> concerns of unintended modifications to a graph. +1
>>
>> Meanwhile, I'd like to caution against confirmation dialogs. Extra clicks
>> quickly annoy users while they work. I suggest no dialog when deleting a
>> single queue or processor, or when moving 'objects' around. Perhaps bring
>> a confirmation dialog into play only when deleting more than 1 'object'.
>>
>> Personally I really like the idea of a read-only mode toggle, even if it
>> was not persisted as a user preference and was only remembered during the
>> current browser 'session'.
>>
>> -- Mike
>>
>> On Tue, Aug 11, 2015 at 9:11 AM, Rob Moran <rm...@gmail.com> wrote:
>>
>>> The consensus view looks good to me. I believe preserving the current
>> model
>>> as Joe describes it is a smart approach.
>>>
>>> An undo action and restrained use of confirmation dialogs are minimal and
>>> should not significantly impede experienced operators. More often than
>> not,
>>> I'd bet a user would expect similar functionality.
>>>
>>> As is evident by the views expressed around read-only/locking, it will be
>>> very difficult to please a majority of users with different user modes
>> and
>>> UI states.
>>>
>>> On Tue, Aug 11, 2015 at 8:29 AM Joe Witt <jo...@gmail.com> wrote:
>>>
>>>> To summarize where we're at ...
>>>>
>>>> Proposed approaches (summary):
>>>>
>>>> - Establish a default read-only view whereby an operator can enable
>>>> edit mode. Use confirmation dialogs for deletes.
>>>>
>>>> - Keep the current model but add support for ‘undo’.
>>>>
>>>> - Let the user choose whether to lock their view or not as user
>>> preference.
>>>>
>>>> - For delete add more protections to make accidents less likely and
>>>> for movement provide an explicit ‘move action’.
>>>>
>>>> The idea of locking seems to have some strong views on both sides and
>>>> both sides have even been argued by the same people (i now count
>>>> myself among that group).
>>>>
>>>> It looks like a consensus view there though is:
>>>>
>>>> - Try to make panning the view of the flow and moving components on
>>>> the flow two specific/discrete actions to avoid accidental movement.
>>>>
>>>> - Add support for undo
>>>>
>>>> - Provide sufficient dialog/protection for delete cases.
>>>>
>>>> This preserves the model whereby we generally trust that the user will
>>>> do the right thing and we’ll do more to help them and that when they
>>>> don’t they will learn and have help to promptly restore a good state.
>>>> How do folks feel about that?
>>>>
>>>> Thanks
>>>> Joe
>>>>
>>>> On Tue, Aug 11, 2015 at 5:11 AM, Alex Moundalexis <al...@cloudera.com>
>>>> wrote:
>>>>> Counterpoint, accidents happen; I prefer to enable users to learn
>> from
>>>>> mistakes and exercise more care next time. You can't remove every
>>> mildly
>>>>> sharp edge without impacting experienced operators; resist the urge
>> at
>>> a
>>>> few
>>>>> comments to dumb down the tool.
>>>>>
>>>>> If some protection is added to the UI, suggest an option for "expert
>>>> mode"
>>>>> that retains original functionality... that way experienced operators
>>>> aren't
>>>>> affected.
>>>>>
>>>>> Alex Moundalexis
>>>>> Senior Solutions Architect
>>>>> Cloudera Partner Engineering
>>>>>
>>>>> Sent from a mobile device; please excuse brevity.
>>>>>
>>>>> On Aug 7, 2015 10:31 PM, "Joe Witt" <jo...@gmail.com> 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 of
>>>>>> the flow. This is the case when panning the screen for example and
>>>>>> 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 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 have
>> an
>>>>>> alternative in mind that would help avoid accidental movement?
>>>>>>
>>>>>> Thanks
>>>>>> Joe
>>>>
>>> --
>>> Rob
>>>
>>
>
>
>
--
Ryan Blue
Software Engineer
Cloudera, Inc.
Re: [DISCUSS] Feature proposal: Read-only mode as default
Posted by Ricky Saltzer <ri...@cloudera.com>.
+1 for read-only by default. It would be nice to have some easy way to tell
if you're in edit/view mode, perhaps the canvas be black/white during view
and color during edit? or, something along those lines.
On Tue, Aug 11, 2015 at 9:57 AM, Michael Moser <mo...@gmail.com> wrote:
> "undo" seems to be the stretch goal that I think that would solve most
> concerns of unintended modifications to a graph. +1
>
> Meanwhile, I'd like to caution against confirmation dialogs. Extra clicks
> quickly annoy users while they work. I suggest no dialog when deleting a
> single queue or processor, or when moving 'objects' around. Perhaps bring
> a confirmation dialog into play only when deleting more than 1 'object'.
>
> Personally I really like the idea of a read-only mode toggle, even if it
> was not persisted as a user preference and was only remembered during the
> current browser 'session'.
>
> -- Mike
>
> On Tue, Aug 11, 2015 at 9:11 AM, Rob Moran <rm...@gmail.com> wrote:
>
> > The consensus view looks good to me. I believe preserving the current
> model
> > as Joe describes it is a smart approach.
> >
> > An undo action and restrained use of confirmation dialogs are minimal and
> > should not significantly impede experienced operators. More often than
> not,
> > I'd bet a user would expect similar functionality.
> >
> > As is evident by the views expressed around read-only/locking, it will be
> > very difficult to please a majority of users with different user modes
> and
> > UI states.
> >
> > On Tue, Aug 11, 2015 at 8:29 AM Joe Witt <jo...@gmail.com> wrote:
> >
> > > To summarize where we're at ...
> > >
> > > Proposed approaches (summary):
> > >
> > > - Establish a default read-only view whereby an operator can enable
> > > edit mode. Use confirmation dialogs for deletes.
> > >
> > > - Keep the current model but add support for ‘undo’.
> > >
> > > - Let the user choose whether to lock their view or not as user
> > preference.
> > >
> > > - For delete add more protections to make accidents less likely and
> > > for movement provide an explicit ‘move action’.
> > >
> > > The idea of locking seems to have some strong views on both sides and
> > > both sides have even been argued by the same people (i now count
> > > myself among that group).
> > >
> > > It looks like a consensus view there though is:
> > >
> > > - Try to make panning the view of the flow and moving components on
> > > the flow two specific/discrete actions to avoid accidental movement.
> > >
> > > - Add support for undo
> > >
> > > - Provide sufficient dialog/protection for delete cases.
> > >
> > > This preserves the model whereby we generally trust that the user will
> > > do the right thing and we’ll do more to help them and that when they
> > > don’t they will learn and have help to promptly restore a good state.
> > > How do folks feel about that?
> > >
> > > Thanks
> > > Joe
> > >
> > > On Tue, Aug 11, 2015 at 5:11 AM, Alex Moundalexis <al...@cloudera.com>
> > > wrote:
> > > > Counterpoint, accidents happen; I prefer to enable users to learn
> from
> > > > mistakes and exercise more care next time. You can't remove every
> > mildly
> > > > sharp edge without impacting experienced operators; resist the urge
> at
> > a
> > > few
> > > > comments to dumb down the tool.
> > > >
> > > > If some protection is added to the UI, suggest an option for "expert
> > > mode"
> > > > that retains original functionality... that way experienced operators
> > > aren't
> > > > affected.
> > > >
> > > > Alex Moundalexis
> > > > Senior Solutions Architect
> > > > Cloudera Partner Engineering
> > > >
> > > > Sent from a mobile device; please excuse brevity.
> > > >
> > > > On Aug 7, 2015 10:31 PM, "Joe Witt" <jo...@gmail.com> 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 of
> > > >> the flow. This is the case when panning the screen for example and
> > > >> 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 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 have
> an
> > > >> alternative in mind that would help avoid accidental movement?
> > > >>
> > > >> Thanks
> > > >> Joe
> > >
> > --
> > Rob
> >
>
--
Ricky Saltzer
http://www.cloudera.com
Re: [DISCUSS] Feature proposal: Read-only mode as default
Posted by Michael Moser <mo...@gmail.com>.
"undo" seems to be the stretch goal that I think that would solve most
concerns of unintended modifications to a graph. +1
Meanwhile, I'd like to caution against confirmation dialogs. Extra clicks
quickly annoy users while they work. I suggest no dialog when deleting a
single queue or processor, or when moving 'objects' around. Perhaps bring
a confirmation dialog into play only when deleting more than 1 'object'.
Personally I really like the idea of a read-only mode toggle, even if it
was not persisted as a user preference and was only remembered during the
current browser 'session'.
-- Mike
On Tue, Aug 11, 2015 at 9:11 AM, Rob Moran <rm...@gmail.com> wrote:
> The consensus view looks good to me. I believe preserving the current model
> as Joe describes it is a smart approach.
>
> An undo action and restrained use of confirmation dialogs are minimal and
> should not significantly impede experienced operators. More often than not,
> I'd bet a user would expect similar functionality.
>
> As is evident by the views expressed around read-only/locking, it will be
> very difficult to please a majority of users with different user modes and
> UI states.
>
> On Tue, Aug 11, 2015 at 8:29 AM Joe Witt <jo...@gmail.com> wrote:
>
> > To summarize where we're at ...
> >
> > Proposed approaches (summary):
> >
> > - Establish a default read-only view whereby an operator can enable
> > edit mode. Use confirmation dialogs for deletes.
> >
> > - Keep the current model but add support for ‘undo’.
> >
> > - Let the user choose whether to lock their view or not as user
> preference.
> >
> > - For delete add more protections to make accidents less likely and
> > for movement provide an explicit ‘move action’.
> >
> > The idea of locking seems to have some strong views on both sides and
> > both sides have even been argued by the same people (i now count
> > myself among that group).
> >
> > It looks like a consensus view there though is:
> >
> > - Try to make panning the view of the flow and moving components on
> > the flow two specific/discrete actions to avoid accidental movement.
> >
> > - Add support for undo
> >
> > - Provide sufficient dialog/protection for delete cases.
> >
> > This preserves the model whereby we generally trust that the user will
> > do the right thing and we’ll do more to help them and that when they
> > don’t they will learn and have help to promptly restore a good state.
> > How do folks feel about that?
> >
> > Thanks
> > Joe
> >
> > On Tue, Aug 11, 2015 at 5:11 AM, Alex Moundalexis <al...@cloudera.com>
> > wrote:
> > > Counterpoint, accidents happen; I prefer to enable users to learn from
> > > mistakes and exercise more care next time. You can't remove every
> mildly
> > > sharp edge without impacting experienced operators; resist the urge at
> a
> > few
> > > comments to dumb down the tool.
> > >
> > > If some protection is added to the UI, suggest an option for "expert
> > mode"
> > > that retains original functionality... that way experienced operators
> > aren't
> > > affected.
> > >
> > > Alex Moundalexis
> > > Senior Solutions Architect
> > > Cloudera Partner Engineering
> > >
> > > Sent from a mobile device; please excuse brevity.
> > >
> > > On Aug 7, 2015 10:31 PM, "Joe Witt" <jo...@gmail.com> 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 of
> > >> the flow. This is the case when panning the screen for example and
> > >> 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 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 have an
> > >> alternative in mind that would help avoid accidental movement?
> > >>
> > >> Thanks
> > >> Joe
> >
> --
> Rob
>
Re: [DISCUSS] Feature proposal: Read-only mode as default
Posted by Rob Moran <rm...@gmail.com>.
The consensus view looks good to me. I believe preserving the current model
as Joe describes it is a smart approach.
An undo action and restrained use of confirmation dialogs are minimal and
should not significantly impede experienced operators. More often than not,
I'd bet a user would expect similar functionality.
As is evident by the views expressed around read-only/locking, it will be
very difficult to please a majority of users with different user modes and
UI states.
On Tue, Aug 11, 2015 at 8:29 AM Joe Witt <jo...@gmail.com> wrote:
> To summarize where we're at ...
>
> Proposed approaches (summary):
>
> - Establish a default read-only view whereby an operator can enable
> edit mode. Use confirmation dialogs for deletes.
>
> - Keep the current model but add support for ‘undo’.
>
> - Let the user choose whether to lock their view or not as user preference.
>
> - For delete add more protections to make accidents less likely and
> for movement provide an explicit ‘move action’.
>
> The idea of locking seems to have some strong views on both sides and
> both sides have even been argued by the same people (i now count
> myself among that group).
>
> It looks like a consensus view there though is:
>
> - Try to make panning the view of the flow and moving components on
> the flow two specific/discrete actions to avoid accidental movement.
>
> - Add support for undo
>
> - Provide sufficient dialog/protection for delete cases.
>
> This preserves the model whereby we generally trust that the user will
> do the right thing and we’ll do more to help them and that when they
> don’t they will learn and have help to promptly restore a good state.
> How do folks feel about that?
>
> Thanks
> Joe
>
> On Tue, Aug 11, 2015 at 5:11 AM, Alex Moundalexis <al...@cloudera.com>
> wrote:
> > Counterpoint, accidents happen; I prefer to enable users to learn from
> > mistakes and exercise more care next time. You can't remove every mildly
> > sharp edge without impacting experienced operators; resist the urge at a
> few
> > comments to dumb down the tool.
> >
> > If some protection is added to the UI, suggest an option for "expert
> mode"
> > that retains original functionality... that way experienced operators
> aren't
> > affected.
> >
> > Alex Moundalexis
> > Senior Solutions Architect
> > Cloudera Partner Engineering
> >
> > Sent from a mobile device; please excuse brevity.
> >
> > On Aug 7, 2015 10:31 PM, "Joe Witt" <jo...@gmail.com> 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 of
> >> the flow. This is the case when panning the screen for example and
> >> 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 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 have an
> >> alternative in mind that would help avoid accidental movement?
> >>
> >> Thanks
> >> Joe
>
--
Rob
Re: [DISCUSS] Feature proposal: Read-only mode as default
Posted by Joe Witt <jo...@gmail.com>.
To summarize where we're at ...
Proposed approaches (summary):
- Establish a default read-only view whereby an operator can enable
edit mode. Use confirmation dialogs for deletes.
- Keep the current model but add support for ‘undo’.
- Let the user choose whether to lock their view or not as user preference.
- For delete add more protections to make accidents less likely and
for movement provide an explicit ‘move action’.
The idea of locking seems to have some strong views on both sides and
both sides have even been argued by the same people (i now count
myself among that group).
It looks like a consensus view there though is:
- Try to make panning the view of the flow and moving components on
the flow two specific/discrete actions to avoid accidental movement.
- Add support for undo
- Provide sufficient dialog/protection for delete cases.
This preserves the model whereby we generally trust that the user will
do the right thing and we’ll do more to help them and that when they
don’t they will learn and have help to promptly restore a good state.
How do folks feel about that?
Thanks
Joe
On Tue, Aug 11, 2015 at 5:11 AM, Alex Moundalexis <al...@cloudera.com> wrote:
> Counterpoint, accidents happen; I prefer to enable users to learn from
> mistakes and exercise more care next time. You can't remove every mildly
> sharp edge without impacting experienced operators; resist the urge at a few
> comments to dumb down the tool.
>
> If some protection is added to the UI, suggest an option for "expert mode"
> that retains original functionality... that way experienced operators aren't
> affected.
>
> Alex Moundalexis
> Senior Solutions Architect
> Cloudera Partner Engineering
>
> Sent from a mobile device; please excuse brevity.
>
> On Aug 7, 2015 10:31 PM, "Joe Witt" <jo...@gmail.com> 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 of
>> the flow. This is the case when panning the screen for example and
>> 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 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 have an
>> alternative in mind that would help avoid accidental movement?
>>
>> Thanks
>> Joe