nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Taft <a...@adamtaft.com>
Subject Re: [DISCUSS] Feature proposal: Read-only mode as default
Date Sun, 09 Aug 2015 00:50:07 GMT
Thinking about it some more, I don't mind the concept of "read only"
toggle.  Maybe it's not set by default, but it could be a really easy UI
element to add somewhere.  Just a little slider-toggle element. [1]

In theory, this might be a UI only feature, it wouldn't strictly need
support in the backend api (just guessing).  The logic is seemingly already
there, similar user experience as non-DFMs.

Anyway, +1 to the concept of read-only toggle mode.  -1 for making it
default, but the user interface element should be easy to work either way.

Also agree that undo support might be free if versioning is added.

[1] http://turbo.premiumpixels.com/wp-content/uploads/2011/04/preview2.jpg




On Sat, Aug 8, 2015 at 3:05 PM, Joe Witt <joe.witt@gmail.com> wrote:

> Ryan - the other useful case for read-only is basically when is
> scanning around the graph and accidentally moves a processor or
> relationship.  By no means a big deal.  The idea here was to make it
> explicit though that the user wishes to go into an edit mode.
>
> I do think the undo mechanism plays well and you're right that we can
> just focus on tightening up the delete case.
>
> Sounds like the prevailing view is to avoid read-only as a mode but
> rather to make it more explicit whenever we delete - and potentially
> move we could make more specific rather than simply them having
> clicked and dragged which is ambiguous with the process of panning.
>
> On Sat, Aug 8, 2015 at 2:57 PM, Ryan Blue <blue@cloudera.com> wrote:
> > I'm not a big fan of having a read-only mode by default. It sounds like
> > something that would be frustrating for users when they try to make
> changes
> > and then have to figure out how to switch modes.
> >
> > I think a clearer picture of the problem we're trying to solve would
> help my
> > understanding. I'm primarily thinking of the delete case you mentioned
> with
> > these comments...
> >
> > If we're talking about accidentally deleting processors, then the current
> > mechanisms (IIRC) work pretty well: not deleting a running processor, one
> > that has live incoming connections, etc. If those rules are
> insufficient, I
> > would explore extending them rather than having a global read-only mode.
> >
> > For the case where the wrong processor is selected because it is off the
> > screen, maybe having the confirmation pop up if anything affected wasn't
> > displayed to confirm? That way we don't have confirmations all the time
> but
> > still don't do unexpected things.
> >
> > I really like the idea of "undo" as well. If that is limited to
> processors
> > that weren't running (because you can't delete ones that are), then that
> > makes the undo operation easier to implement.
> >
> > rb
> >
> >
> > On 08/08/2015 11:31 AM, Joe Witt wrote:
> >>
> >> I can dig the user pref aspect but it would mean we start storing user
> >> prefs which is a bummer.
> >> On Aug 8, 2015 1:42 PM, "Tony Kurc" <trkurc@gmail.com> wrote:
> >>
> >>> Personally not a fan of the idea. Maybe something analogous to
> something
> >>> like 'lock the taskbar' in Windows that can have a system default
> setting
> >>> and a user preference of on or off.
> >>>
> >>> On Sat, Aug 8, 2015 at 11:44 AM, johny casanova <
> >>> computertech2124@gmail.com>
> >>> wrote:
> >>>
> >>>> I agree it is easy to move it delete something by mistake. Some flows
> >>>> are
> >>>> huge or are using,more resources and are slower to load and you can
> >>>> accidently do something by mistake. I believe the "are yous sure u
> want
> >>>
> >>> to
> >>>>
> >>>> delete?" its a good start.
> >>>> 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
> >>>>>
> >>>>
> >>>
> >>
> >
> >
> > --
> > Ryan Blue
> > Software Engineer
> > Cloudera, Inc.
>

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