[PATCH] Turn Powerdevil suspend notification into a dialog

[Aaron J. Seigo]

On September 23, 2009, Thomas Lübking wrote:
> Am Wednesday 23 September 2009 schrieb Aaron J. Seigo:
> > or "how to piss off a user because the developer thinks they know better"
> 
> just to make that clear:
> i'm not speaking about status messages like "mid battery" or "low battery"
> i'm talking about the moment before the system dies.

yes, that was evident and obvious.

> > > and /outside/ the workspace/workflow.
> >
> > power management is generally perceived as part of the workspace. just
> > like shutting down, restarting, etc are.
> 
> likely a philosophical matter ("is your death part of your life", "is a
>  border part of something") 

it's not a matter of philosophical masturbation as in your examples. rather:

the battery notifier is part of the workspace.
notifications are part of the workspace.
anything that does not come directly from an application the user has 
intentionally launched and which deals with the state of the state of the 
system (running applications, resource usage and control, window interaction, 
power and network management control) are all part of the workspace.

this gives us a clear distinction between "what the computer/system itself is 
doing to support your efforts" and "what i (the user) am purposefully doing 
with this computer/system as a tool to achieve my goals/aims/tasks".

this allows the user to always know that what they see that looks "like an 
application" does indeed "belong" to their actions and that anything that 
"looks like the workspace" belongs to the system's "inner mechanisms".

this is a purposeful and non-accidental part of the design philosophy we are 
employing in the Plasma project.

>  - but you dropped "workflow"... ;-P

because i didn't realize i had to be pedantic. ;) let me add it here for you 
then: "or the workflow that is part of the KDE 4 workspace interaction".
 
> > the event can and will be ignored.
> 
> no: the /warning/ can and will (you prooved that)
> the event however will take place and (as mentioned) the user can not
>  schedule its handling nor ignore it (either he does some or "suffer" the
>  suspense) good news:
> if you're out of the room, it won't break your workflow either ;-)

the event i referred to was the notification event. we are all in agreement 
that the event of suspending your computer will take place unless some action 
is taken.
 
> > this is really basic usability: don't get in the way of the user, don't
> >  enter modal states. it will backfire if we try to run around that.
> 
> how would you describe a shutdown/suspense then?

you're misusing the term "mode", or at least not using it in the same way i 
would expect it to be used in an HCI discussion:

http://en.wikipedia.org/wiki/User_interface#Modalities_and_modes

ignoring that, there are two cases when shutdown/suspend happens:

* the user takes action to trigger the shutdown/suspend. this is a state the 
machine enters specifically because the user requests it. as such, it is 
perfectly ok, and in fact desirable, to interrupt what the system is doing. no 
interruption of the user happens, however, because they have already changed 
what they are doing and are simply asking the computer to catch up with this 
change in their own state

* the system enters shutdown/suspend on its own due to either a software 
failure (e.g. if power devil were to simply decide to shut things down or a 
hardware failure), which is something we can ignore in this conversation since 
it's simply a defect, OR when there are insufficient resources (e.g. power) to 
physically keep the machine going.

this last case is special: we have no choice but to make the system start 
heading towards shutdown/suspend because of the state of available resources.

that, however, is NOT the question at all. the question is: once the system 
has knowledge that a system-initiated shutdown/suspend will be necessary, how 
do we communicate this to the user and what response is the user likely to 
have?  we have covered this elsewhere in detail already, i believe. :)

> > or just as likely they'll quickly get rid of the annoyance and forget.
> 
> A big fat warning like
>                                        EMPTY BATTERY.
> Plug in an AC adaptor or the system will suspend in 20.. 19.. seconds
> 
> Is imho not an "annoyance" i'd "quickly get rid of [...] and forget" -
>  sorry.

yes, i understand you are operating on your opinion. i'm operating on 
information gathered by reading published materials and doing field work. i 
can't argue opinion because there is no basis for it either than one's own 
intuition and internal logical constructions. so i won't even try to.

however, due to what i've read over the years and field work i've done in 
support of work in Plasma, i will not allow such a dialog to enter software i 
have any say in.

you are free to disagree based on your opinion.
 
> > and, because i'm in repetition mode already, where are the bug reports or
> >  user observation saying "i didn't notice that thing and so i lost data /
> >  time / something else bad"?
> 
> If there wasn't some demand, there likely wasn't this patch...

i ask "what's the basis for this" and you say "it is its own basis: because it 
exists, it must have a reason for existing." the fallacy inherent in such 
logic should be obvious.

let me offer an alternate explanation: the patch was created by a member of a 
team (Ayatana) that has removed the current mechanism of providing user 
interaction during system initiated suspension. specifically, they removed 
actions from notifications and now have a non-interuptable notification that 
happily counts down to oblivion. their solution is to turn it into a dialog. 

so they post a patch. they don't mention that this is suddenly an issue for 
them because they've neutered their notification UI in terms of user 
interaction. we get this sprawling discussion where people assume that the 
patch was made because there was an existing problem when the truth is that 
the problem is completely self-contrived.

> I just wanted to propose a "how to make a dialog not take accidental input"

yes, by making it non-interactive for 2.5 seconds. so now we interrupt the 
user but then prevent the user from removing the interruption for an arbitrary 
period of time. the ideas are getting worse, not better.

> and then pointed out that imho it's very much ok to be a "little more"
> intrusive on this specific item.

a little more, sure; breaking the notification strategy is unnecessary 
however.

> But i always plug in my AC (so no message at all) or can't do anything
>  about the suspense anyway - no data loss so far. toctoctoc =D

yep; this is what people tend to do as far as i've been able to discern. which 
is to say, there is no actual problem here.

we could improve the notification, but the notification strategy itself is not 
problematic.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090923/376c7afc/attachment.sig>