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 <[email protected]> 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" <[email protected]> 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: [email protected] > > > To: [email protected] > > > > > > 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 <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 < > > >>>>> [email protected]> > > >>>>> 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" <[email protected]> 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
