battery plasmoid and remaining time..
Aaron J. Seigo
aseigo at kde.org
Sun May 17 20:06:57 CEST 2009
On Friday 15 May 2009, Celeste Lyn Paul wrote:
> Percentage as an indicator to how much battery power remains:
> * We're all geeks and pretty much treat our laptops like they were the
> security blanket we had when we were 3. Sane/normal people don't know much
> about their hardware or battery capacity.
please don't talk down to me, or the rest of the people on this list. i don't
treat my laptop like a security blanket, and i don't appreciate being referred
to as someone outside the "sane/normal" group.
> They just want to know how much
> longer until they need to shutdown/plugin.
no one is arguing this. this is not the point up for discussion. it is
something no one disagrees with.
how many more ways do i need to say this?
the issue is not "would it be good to show the time left?" because the answer
is pretty obvious: yes.
the issue is: "can we actually deliver that?" and the answer is: not really.
now, while it may work "well enough" for some people and "well enough" for
some work patterns, it will not work well enough for many other scenarios.
and here's my entire issue with it: when the computer LIES to you, you trust
it less. when the computer's information is SUSPECT you then, even
unconsciously, are left with some mental processes second guessing the system.
such an individual will never be confident with or comfortable in front of
that computer, at least not completely.
it is better to serve up a more primitive feature set that has at least a
chance of being true than a more complete feature set that breeds mistrust and
> * Reporting percentage seems to be pretty useless when it matters. What
indeed. i hate knowing that my car has only 1/4 tank of gas in it. what does
that mean, really?
> does "30% remaining" mean? All it does is force me to make a mental
> calculation on my own instead of the computer helping with the work. Also,
yeah, except that you're asking for magical fairy tale intervention. it'd also
be awesome to have the computer write this email. it lacks the cognitive
abilities to do so, however, and so we rely on me doing it.
> not everyone knows that Lithium ion batteries degrade over time, so
> estimating 30% of factory battery capacity is just as inaccurate as the
> computer calculating it.
erm. what? % of battery tends to be a hell of a lot more accurate than total
time. saying that "a broken battery doesn't work well, so we should fuck it up
for all use cases" is pretty stupid.
> Time as an indicator to how much battery power remains:
> * Subject to current computer usage and fluctuates throughout the session
> * Subject to the accuracy of hardware/driver reporting
> * Often grossly inaccurate, and so one of the arguments is why show it at
> all if it isn't useful?
no, the argument is "why undermine user trust in a system by purposefully
delivering information we know they can't trust".
> * How many of the hardware/driver related problems can be fixed? Is this
not really relevant to this discussion, and i'm sorry i ever brought that part
of it up, as it's a current-term reality that should hopefully be fixed over
time while this discussion has become one about the general idea of the nature
> * What is the extent to the "grossly inaccurate time reporting" issue? Is
> it only with some hardware, much hardware, most hardware?
this is absolutely, 100% IRRELEVANT. even with 100% perfectly accurate
hardware, you still can't fortell the future and what i'll be doing with my
computer in an hour. or can you?
> My thoughts:
> * I really believe that only reporting percentage is not enough to meet
> user needs.
and yet cell phones and car gas tank levels say otherwise.
yes, it's not the best thing we can dream up, but it's what we can actually
usability dreaming meat implementation reality.
> Even if it is inaccurate and mostly a guess we should find a
> way to provide a better time estimate.
can i have a pony while you're at it?
> * What is reported will always be inaccurate and the best we can hope for
> is "close enough",
right, so we teach the user "don't trust what the machine tells you. it's all
kind of lies." great for user trust in the system, isn't it? great for
teaching the user to learn to ignore (due to trust) the desktop shell and just
concentrate on that application.
in your quest for a "more usable feature" you're bypassing some pretty
fundamental psychological side effects.
> but always erring on the side of caution.
what does that even mean?
> * Since time is at best an estimate, reporting a range rather than
> qualifying an absolute time as "estimated" seems to be the better time
a range would be nice. i have yet to see a way to come up with this on a
modern laptop (as opposed to a fixed device like the n810)
> Ultimately, what users want to know is how much time they have left so they
> can plan their unplugged activity. If they don't want to know how much
> time, then glancing at the battery icon is sufficient information,
> reporting percentage again in the popup is just repeating information the
> user can already access.
it's level of detail. the battery icon gives a rough measure. the percentage
gives a finer grained measure.
> Reporting percentage because it is more accurate
> will only force the user to do the calculation themselves if they know
> enough about their hardware to so.
you don't need to know your hardware well to see that since you unplugged a
couple hours ago you are now down to ~30% and it's dropping more quickly.
> This is silly -- we shouldn't be making
> the user do work the computer can do.
who said the computer can do this work? hell, i thought that's what we were
saying all along: the computer CAN'T do this work.
> If estimating time is inaccurate then
> we need to find ways to fix it and make it more accurate, not remove the
ok, show me the algorithm.
> * Zack mentioned high and low wattage for different use
> scenarios. Could we calculate a high and low estimate and provide a range?
> Or would this cost too much?
it would likely be similar to mind reading given the various hardware
combinations kde is run on. well, mind reading or a rather impressively large
database. don't know who'd make and populate that with accurate data, either.
> * What about an artificial range imposed on whatever is reported? If the
outside of a fixed device (e.g. the n810) i doubt this is realistic.
> * Do we know when power usage is heavy (CPU, wifi, screen brightness,
> disk)? When these things are high, can we provide a hint about power
... and devices are plugged in or a dozen different possibilities.
> I'm thinking the easiest solutions would be to keep a few estimate
> calculations over the period of 5-10 minutes to create a trend of remaining
> time. This could help offset spikes in power usage from disk access and bad
> flash sites and make the estimate more accurate.
no, it won't. because the last 5 hours of usage at idle don't account for the
next 20 minutes spent watching flash video on youtube.
> Maybe someone can write a
> little testing widget that collects power usage information every n
> minutes. If we get 20-30 people to use it for a week, we could use the data
> to optimize the trend accuracy to cost.
i don't see how this would help in the cases that lie outside the norm at all.
> We can also experiment with labelling to see how to best indicate the
> concept of "estimated". I imagine it could either be through the label
> ("Estimated time remaining"), the time data ("2h 25m to 2h 45m remaining"),
> or some other indicator ("2h 25m remaining (high power usage)).
come up with the algorithm to figure that on a random laptop and you get a
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 Software
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090517/1be82c6a/attachment.sig
More information about the Plasma-devel