Powerdevil notifications

[Scott Kitterman]

On Tue, 29 Sep 2009 10:22:33 -0400 Celeste Lyn Paul <celeste at kde.org> wrote:
>On Tue, Sep 29, 2009 at 8:05 AM, Sebastian Kügler <sebas at kde.org> wrote:
>> On Thursday 10 September 2009 02:17:44 Yuriy Kozlov wrote:
>>> 2009/9/9 Aurélien Gâteau <aurelien.gateau at canonical.com>:
>>> > As you probably know (at least if you are using KDE4 on a laptop),
>>> > Powerdevil shows a notification when you are running out of power and it
>>> > is about to suspend/hibernate/shutdown the computer.
>>> >
>>> > This notification provides an action to cancel the suspend process. This
>>> > is the only notification I found within KDE which could cause a real
>>> > problem when using Ayatana notifications.  Gnome-power-manager used a
>>> > similar notification, and the notification was turned into a dialog, the
>>> > argument being that the program is about to do something very drastic,
>>> > so it is OK to show a dialog in this situation.
>>> >
>>> > I would like to make a similar change in Powerdevil.  I think this
>>> > change would be a good idea even when using regular KDE notifications
>>> > (there has been some discussion on the subject on kde-core-devel@, with
>>> > mixed opinions, but I think it could be upstreamed).  I attached a
>>> > mock-up of the dialog I would like to implement.  What do you think
>>> > about this?
>>> >
>>> > Aurelien
>>>
>>> I am for this becoming a dialog.  When it has come up, I never seemed
>>> to get down there in time.  Though I thought I did -- it seemed more
>>> like the button just didn't do anything!  Regardless, it's an urgent
>>> message and something will most certainly be interrupting my work in
>>> 10 seconds if I don't act on it, so it should be a dialog.
>>
>> I object (also as a Kubuntu developer):
>> Merging this patch will change the behaviour of an upstream component significantly,
>> violating basic design rules of the Plasma team. The Plasma team has taken a very
>> conscious choice here, and explained that at length in the thread on kde-core-devel
>> linked below.
>
>The problem is the chance of the message being missed or delayed in
>viewing is too great when the message is displayed in a notification
>instead of in the center of the screen. For such a critical message,
>this isn't acceptable. Bad things could happen if the user doesn't
>address the message in time. Notifications are often used to keep the
>user updated on status or present unimportant information at a
>location which isn't distracting when the user is engaged but
>noticable when they have available attention resources. The computer
>taking control and automatically suspending is not a minor matter. It
>is a response which in an attempt to help the user it has taken
>control from them. The user must be aware of this and be allowed to
>regain control immediately. A notification just isn't sufficient.

In the upstream discussion this point was raised, but no examples of the notification being missed could be found.

>Persistence in the corner wont help because it is the animation which
>gains the user's attention, not the presentness of the display.
>Notifications also have the potential for learned behaviors such as
>banner blindness (where the user gets used to junk in a certain
>position and trains themself to ignore it) and automatic
>click-to-close without reading the display. This could lead to a
>potentially damaging situation if the computer suspends on it's own
>from a minor "WTF is my computer doing" reaction to very serious data
>loss due to inability for the hardware to successfully suspend. There
>are also the cases where the user turns off notifications or is
>running in a display mode which represses notifications (such as
>watching a movie).

Do we have such a display mode in KDE yet?  There was also some discussion about this and notification priority that led me to believe this was a future capability issue and not a present risk.

>Some people on the Plasma team have taken a seemingly Raskinian
>philosophy when it comes to modal interfaces and popup dialogs, but
>that does not make modal interfaces and popup dialogs evil, simply
>misused. May I remind you that Raskin also promoted two other design
>ideals: keeping the user in control and never allowing the system to
>do harm to the user.

All quite sensible, but I think this needs to be sorted out upstream.

>It's not like users hit Critical very often, and when they do, they
>probably damn well need the reminder that their computer is about to
>die. Remember, there is also the ability to "Warn" at a higher
>percentage (is the default 10%?) which is absolutely suitable as a
>popup notification.
>
>So in summary, a more obvious display, such as in the middle of the
>user's workspace (what the implementation is, I don't care) of the
>critical warning is a good thing because:
>
>* It keeps the user in control
>* It reduces the potential for damage
>* Provides more space to design user reaction

I think this makes sense.

>Notifications are less than optimal for such a critical piece of
>information because:
>
>* There is a high potential for the notification to be missed or not
>attended to in time

I disagree that the potential is high.  Given a 10 - 30 second timeout, the user needs to be paying attention or it's too late no matter how you let them know.

>* There is potential for damage

Only is supend is bugged.  If this is the case, the user would be much better off changing the power settings to not suspend than to depend on being at the machine and paying attention at the right moment.

>* There is less room to design user reaction
>
>I feel like I ought to reference the 3 Laws of Robotics.
>
I agree with your analysis, except I think that this risk of the notification being missed is low.  The main problems we have with this notification can be solved without changing it to a dialogue (I understand agateau provided a patch upstream to change the timeout to 30 seconds that has been accepted).

While I agree that a dialogue would be better here, I do not agree that it's enough better to intentionally create permanent upstream divergence over.  

I think the best plan for Karmic is to drop this patch and instead use the one from upstream that extends the timeout to 30 seconds.  Then in Lucid we can see how this debate is finally resolved in KDE.

Scott K