Re: [DISCUSS] Feature proposal: Read-only mode as default
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 joe.w...@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
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 joe.w...@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 joe.w...@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
+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 moser...@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 rmo...@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 joe.w...@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 joe.w...@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
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: a...@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 joe.w...@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 b...@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 trk...@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 computertech2...@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 joe.w...@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.
