battery plasmoid and remaining time..

[Aaron J. Seigo]

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 
ultimately contempt.

> * 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 
of time-based-reporting. 

> * 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 
deliver on.

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
> solution.

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
> problem.

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
> saving? 

... 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 
lollipop.

-- 
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
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090517/1be82c6a/attachment.sig