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