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 <jsk...@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 <b...@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 <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 >>>>> >>>>> >>>> >>> >>> >>> >> >> -- >> Ryan Blue >> Software Engineer >> Cloudera, Inc. >>
