--nextPart1752340.Jc3AgWR7Vd
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On September 23, 2009, David Nadlinger wrote:
> Furthermore, the battery level/suspension notification is not exactly
> something _unexpected_ =E2=80=93 the user was notified at least once abou=
t the
> remaining battery power reaching a low level.

not to mention you have the battery icon down there. i actually asked vario=
us=20
non-technical users about this early this year to get a feel for how the=20
battery notification system works for people (or doesn't). the  #1 thing=20
people said was they look at the battery icon after they've been uplugged f=
or=20
a while and see what it says.

notification of power issues, it seems, is useful in two primary cases:

* unexpected power shortage (e.g. you thought you were plugged in, but you=
=20
aren't, something that can happen if you don't plug it in properly for=20
instance; or your battery's life is diminishing through regular wear and te=
ar=20
over time and you haven't noticed yet)

* someone gets very distracted and loses track of time (very possible)

otherwise, the battery indicator itself is enough for nearly everyone it=20
seems. so these notifications are needed and are useful but do not need to =
be=20
IN YOUR FACE. they are in the general case relatively unuseful. they are=20
emergency measures.

btw, the most common response to "you have no battery left" seems to be to=
=20
plug your computer in if there is power nearby or to shut down the system a=
t=20
that point. so if power devil doesn't stop it's "i'm going to suspend" when=
=20
the power is plugged in, that would be quite unexpected for the user and a=
=20
common failure scenario in that case. which is to say, that in the small % =
of=20
cases where this notification is needed one of the two most common operatio=
ns=20
will prevent any interaction from being needed if power devil does it "righ=
t".=20
that means giving enough time to get a power cord and plug it in and auto-
aborting when power returns.

increasing the time out from 10s to 30s or maybe even 60s should give enoug=
h=20
time to plug the computer in; and hopefully power devil already auto-aborts=
=20
the suspend action in that case. (Dario, can you confirm that?)

(note that i'm very well aware that my observations as above are not=20
scientific studies. i'd love to have such resources at my disposal, but i=20
don't. :) the observations are, however, designed to gather relevant data t=
o=20
compare with what we are actually doing and often result in changes in how =
we=20
implement things.=20

in my experience, this is more than most people who work on these issues ca=
n=20
say. i experience some exasperation when dealing with these topics because=
=20
people too often weigh in before researching published materials or doing a=
ny=20
field work of their own.)

> I am, however, strongly in favour of extending the timeout or making
> the notification more =C2=BBnoticeable=C2=AB (whatever this turns out to =
mean)
> if this helps some users =E2=80=93

agreed.

> it is just that it has never been a problem for me.

i honestly doubt it's a problem for nearly anyone. i keep asking the questi=
on,=20
nobody answers except with "well, on an old version of KDE" or "with broken=
=20
kernel support".=20

> As for the (K)Ubuntu issue: I must admit that I have never dealt with
> the notification system from a developer point of view, and neither do
> I know notify-osd, but I really don't understand the fuss about this:

when you look at the patches to dozens of applications that are necessary t=
o=20
make this all work properly and how it makes Ubuntu systems very different =
in=20
behavior from other F/OSS offerings resulting in a fracturing of the user=20
experience in an already small market (the phrase that springs to my mind i=
s=20
"dividing one's own house so that others may more easily do the conquering"=
),=20
the reason for the fuss becomes more apparent.

i'd be honestly happy to ignore this whole situation and see, as a curious=
=20
onlooker, how it pans out for Ubuntu users over the next couple years. but =
i=20
keep getting sent patches related to it that i'm not interested in. and yet=
=20
they keep coming. this patch and the resulting thread is a nice example.

i'm happy to see Ayatana experiments if only because trying new ideas is=20
something i think is a generally good thing, but i'm not pleased to spend m=
y=20
time on things i don't even agree with due to it spilling repeatedly and=20
unwanted over the fence and into my yard.

> If there is a (de facto-?)standard which covers actions in
> notifications, frankly, why should we care about a downstream
> application which does not adhere to this? If not, we probably should
> really try to get others to support this useful feature, rather than

the F/OSS implementations *do* support actions in notifications. that's=20
because the upstreams all agree that actions are useful and should be in th=
e=20
visible user interface. this is a point that Canonical departs from their=20
upstreams on.  this is something the freedom in our software allows for. :)

=2D-=20
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

--nextPart1752340.Jc3AgWR7Vd
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEABECAAYFAkq6Xa4ACgkQ1rcusafx20PHKACgqoENkAGr6uU5HZOynl+4i/6D
m2sAn2+x0DMrAF6LIgYE/SkOrFLPa/ka
=1nJC
-----END PGP SIGNATURE-----

--nextPart1752340.Jc3AgWR7Vd--