nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Witt <joe.w...@gmail.com>
Subject Re: [DISCUSS] Feature proposal: Read-only mode as default
Date Mon, 17 Aug 2015 13:51:41 GMT
Ok all the thread has died down and reading where there is a strong
consensus the main thing that comes out the other end here is the
desire for 'undo'.  I believe this is well captured in [1].

Other ideas where presented here that are also interesting and perhaps
once we get make progress on the other more clarity will occur on
those.  Great discussion all - thanks!

Joe

[1] https://cwiki.apache.org/confluence/display/NIFI/Configuration+Management+of+Flows

On Fri, Aug 14, 2015 at 8:13 AM, Joe Skora <jskora@gmail.com> wrote:
> +1 for read-only as a toggle with a system property to configure the
> default.
>
> +1 (+2 +3) for Undo.  Undo is a common and expected application feature
> even in web UIs that eliminates a lot of pain and anxiety.  But Undo is
> complicated, especially in a web UI, so perhaps it could be phased-in?  I
> see a lot of value in even one level of undo, like GMAIL, so that might be
> a good target for a first phase.  That could eventually be expanded to
> multiple levels with less pressure and more time to get it right.
>
> On Tue, Aug 11, 2015 at 12:22 PM, Ryan Blue <blue@cloudera.com> wrote:
>
>> +1 for the consensus view as Joe summarized it.
>>
>> I also agree with only using confirmations sparingly.
>>
>> rb
>>
>>
>> On 08/11/2015 07:07 AM, Ricky Saltzer wrote:
>>
>>> +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.mw@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 <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
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>> --
>> Ryan Blue
>> Software Engineer
>> Cloudera, Inc.
>>

Mime
View raw message