nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Moser <moser...@gmail.com>
Subject Re: [DISCUSS] Feature proposal: Read-only mode as default
Date Tue, 11 Aug 2015 13:57:58 GMT
"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 <rmoran@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.witt@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 <alexm@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.witt@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message