+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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> 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 <[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 >>>>>>> >>>>>> >>>>> -- >>>> Rob >>>> >>>> >>> >> >> >> > > -- > Ryan Blue > Software Engineer > Cloudera, Inc. >
