+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...@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 <rmo...@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.w...@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 <al...@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.w...@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.
