If we're talking about read-only mode as a way to avoid moving
processors when moving around on the graph, what about implementing
something slightly different? What about having a toggle between
drag-to-scroll and drag-to-move? Then users could keep the toggle in
drag-to-scroll most of the time (and undo would put things back when the
inevitable accident happens).
Then deletes would be handled by more sophisticated rules, like not
deleting processors that are off the screen without confirmation.
rb
On 08/10/2015 12:58 PM, Dan Bress wrote:
+1 to exactly what Mark described in his last email for a system wide
preference.
Although I'm curious how you leave read-only mode and get into edit mode? And
how do you leave edit mode and go back to read-only mode?
On one hand, if I do not intend to edit the graph and I accidentally move a processor I
probably don't want it to prompt me "do you want to enter edit mode?"
-In read-only mode, I think it would be a nice user experience to click
anywhere on the graph(including on a processor) and it moves the entire graph.
On the other hand, if I right click a processor and hit configure I'd like to leave
read-only mode and go into edit mode. I'm not sure I'd even want to be prompted with
"do you want to enter edit mode?" here since I obviously do.
Dan Bress
Software Engineer
ONYX Consulting Services
________________________________________
From: Mark Payne <[email protected]>
Sent: Monday, August 10, 2015 3:43 PM
To: [email protected]
Subject: RE: [DISCUSS] Feature proposal: Read-only mode as default
I'm definitely a +1. I accidentally drag processors all the time when I'm
panning around a large graph.
I can understand how someone would get annoyed with this, though, and I can
also appreciate the desire
to not start storing user preferences. However, I think we should probably at
least supply a system-level
configuration for whether or not to have "read-only" the default mode. Then
administrators can turn it on
or off, depending on the users of the system.
----------------------------------------
Date: Sat, 8 Aug 2015 20:50:07 -0400
Subject: Re: [DISCUSS] Feature proposal: Read-only mode as default
From: [email protected]
To: [email protected]
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 <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 <
[email protected]>
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" <[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
--
Ryan Blue
Software Engineer
Cloudera, Inc.
--
Ryan Blue
Software Engineer
Cloudera, Inc.
