All,
Looks like I should be good now. Thanks.
Brandon
On Mon, Aug 10, 2015 at 4:39 PM DAVID SMITH
wrote:
> All
>
> That certainly cured the problem in my case.
>
> Dave
>
> Sent from Yahoo! Mail on Android
>
> --
> * From: * Brandon DeVries ;
> * To: * dev@nifi.apa
James,
Instructions on managing your Apache mailing list subscriptions can be
found here:
http://apache.org/foundation/mailinglists.html
Brandon
On Tue, Aug 11, 2015 at 12:14 PM James Cornell
wrote:
> I'd like to OPT out of the email lists.
>
+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 durin
I'd like to OPT out of the email lists.
+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 wrote:
> "undo" seems to be the stretch go
"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
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 sim
I think "undo" is the most important part here. I agree with Alex's
statement, "accidents happen; I prefer to enable users to learn from
mistakes and exercise more care next time." Delete confirmations may be
fine (although I suspect they would begin to annoy me fairly quickly... if
it's just for
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 us