+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
