generic support for checkbox with "do not ask again" for trivial confirmation dialogs. There are several requests throughout the UI to add an extra confirmation, but if we do that it will become too annoying for frequent users. A checkbox would be a good solution, with some additional dialog listing all the remembered answers and reset them. I think we should be fine with html5-storage client-side persistence only
personally, I am opposed to this type of change; most confirmation dialogs are there in order to prevent a destructive (to a certain extent) operation in case the user did it by mistake or similar. in my OS, for example, when I "shift-delete" something (to remove it permanently), I am getting an 'are you sure' confirmation dialog without an option for "do not ask me again". IMO, a "do not ask/show again" is more relevant for all sorts of "tip of the day" pop-ups that are displayed once you login/start an application, and similar. not for potentially destructive operations. putting a UserExperience keyword, will be further discussed.
(In reply to Einav Cohen from comment #1) > personally, I am opposed to this type of change; most confirmation dialogs > are there in order to prevent a destructive (to a certain extent) operation > in case the user did it by mistake or similar. one of the reason is that we are deliberately not adding confirmation dialogs (despite being asked so) for non-destructive actions exactly because of the concern that it would be too annoying for advanced users. So it's a prerequisite in fact
It sounds to me like we need to be sure to understand which actions should be considered destructive. I'd agree with Einav in that any destructive action should absolutely have a confirmation dialog. Are there specific actions or use cases in which users have complained about needing to confirm too many actions? We should reconsider these actions rather than allow for users to dismiss these messages all together in my opinion. Best, Liz
(In reply to Liz from comment #3) >... > Are there specific actions or use cases in which users have complained about > needing to confirm too many actions? > ... Scott?
(In reply to Einav Cohen from comment #4) > (In reply to Liz from comment #3) > >... > > Are there specific actions or use cases in which users have complained about > > needing to confirm too many actions? > > ... > > Scott? As Michal asked for this and we have no customer tickets on this, adding needinfo to Michal. In general I think a good option would be to allow disabling all confirmation boxes individually, but allowing only non-destructive ones to be done in the box itself with 'do not ask again' check box and all other via config file that only advance user will use, if he looks for this option. It's a nice to have and consider at some point.
(In reply to Yaniv Dary from comment #5) > (In reply to Einav Cohen from comment #4) > > (In reply to Liz from comment #3) > > >... > > > Are there specific actions or use cases in which users have complained about > > > needing to confirm too many actions? > > > ... > > > > Scott? > > As Michal asked for this and we have no customer tickets on this, adding > needinfo to Michal. this is coming from customers; the feature is needed so we can implement the requests for additional confirmation dialogs for various tasks. This is coming up in the past cca 2 years for random acions but we don't want to add more dialogs without the ability to not show it again since what's useful for one customer would be annoying for another. > In general I think a good option would be to allow disabling all > confirmation boxes individually, but allowing only non-destructive ones to > be done in the box itself with 'do not ask again' check box and all other > via config file that only advance user will use, if he looks for this > option. It's a nice to have and consider at some point. what's destructive and what not might be highly subjective. Depending on the use of the system e.g. removing VM is a destructive thing..but for testing when you remove tens of VMs a day not so much...(though for VM we have delete protection;-)
another annoying occurrence is in user portal while opening VM console when the guest agent is not running. There's a warning dialog "Could not connect to the agent on the guest, it may be unresponsive...", after dismissing the dialog the console continues to open