nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Blue <b...@cloudera.com>
Subject Re: [DISCUSS] Feature proposal: Read-only mode as default
Date Tue, 11 Aug 2015 16:22:01 GMT
+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