nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Payne <marka...@hotmail.com>
Subject RE: [DISCUSS] Feature proposal: Read-only mode as default
Date Mon, 10 Aug 2015 21:17:40 GMT
Accidentally moving processors is the main reason that I like this idea. However, I would like
to see it
truly in read-only mode. If I go to Configure a processor, I may still not want to edit the
processor.
I may just want to view the configuration and I'd like to ensure that I don't accidentally
change (or delete)
something.


----------------------------------------
> Date: Mon, 10 Aug 2015 13:02:35 -0700
> From: blue@cloudera.com
> To: dev@nifi.apache.org
> Subject: Re: [DISCUSS] Feature proposal: Read-only mode as default
>
> 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 <markap14@hotmail.com>
>> Sent: Monday, August 10, 2015 3:43 PM
>> To: dev@nifi.apache.org
>> 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: adam@adamtaft.com
>>> To: dev@nifi.apache.org
>>>
>>> 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.
>>>>
>
>
> --
> Ryan Blue
> Software Engineer
> Cloudera, Inc.
 		 	   		  
Mime
View raw message