"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 >
