battery plasmoid and remaining time..

[Aaron J. Seigo]

On Thursday 14 May 2009, Sebastian Kügler wrote:
> > can someone provide a justification, other than idiot pacification, for
> > r#915184
>
> Yes. The percentage is even less relevant, a bad battery can show 100% and
> still go down within two minutes.

if my battery is going bad, that's one thing and i deserve everything i get 
with that. nothing will save me then. but point to a defective corner case in 
hardware is not justification for anything. we're talking about generally 
working batteries, aka 99.9%+ of our use cases here.

> The time remaining gives at least an approximation of what the user can
> expect, and does so in a *meaningful* way (by providing an absolute
> number).

it is not an absolute number, it's a made up number. it's a guess. you call it 
an absolute number only because it comes in cardinal digit form.

> As to (a), those machines or drivers should be fixed instead of removing a
> very popular and often useful features from the UI.

ok, i give you this.

> (b) is a fair point partly. Though I'm not sure it's really relevant.
> Here's what happens in my mental model: The user checks the percentage and
> tries to interpolate from that if he can finish reading this text, writing
> this long email, or watching this movie. 

no, it's much simpler than that: i look at it and see i have 10% left and know 
i'd better find a plug sometime in the near future. there's no interpolating.

> For all those cases, the
> percentage isn't interesting, she needs to know the time (it'll take 40
> minutes to finish the task, the movie lasts another 1.5 hours). 

yes, and that number it lies to me doesn't really help. because it's a _lie_. 
we know it isn't accurate. it's a guestimate based on the user and the 
computer not changing workload and the battery discharging at a reasonably 
predictable rate.

> Note that
> in those cases, the activity will usually remain mostly the same, hence the
> consumption of energy, and hence the time reported.

since we're talking about something that _turns the machine off_ i don't think 
"usually" is good enough. nor do i think that activity remains mostly the same 
in many typical user work loads.

> In any case, the user does need the time, not the percentage.

oh, i agree. if i could have an accurate time that'd be awesome. but the 
question is not "is having the time useful or needed", the question is "can we 
deliver that information accurately to fulfill such a need" .. answer is "no".

> I often found
> myself trying to guess the remaining time from the percentage, and that's a
> very complex thing to do (you have to measure over a period of time).

you know, in the BR about this i suggested as an alternative showing "time 
since last charge" or something like that. that's an absolute number we can 
provide, one we can have confidence in.

it's not perfect, but it's actual, real, information that can be taken as 
truth, not an ever juggling number that bobs and weaves depending on whether 
i'm reading email or watching something on cnn.com.

> You're also talking about data loss, which I think is an invalid point. The

tell that to the data i lost thanks to this same feature in kde3.

on fun, though non-data losing event, was a time a cron job fired up that spun 
disk madly when i purportedly had 15-20 minutes left of time (iirc i was just 
reading some text.. very much non-taxing stuff so i had time, or so i was lied 
to). imagine my surprise when the computer abruptly turned itself off far in 
advance of even the 15 minute mark.

that was a surprise. i was betrayed by the signs on the computer. while bad 
things might happen in life, they should never come at the hand of a 
purposefully added feature that _lies_.

> automatic suspending mechanism is still percentage-based, so the time
> display doesn't have any influence there, the machine will warn and go to
> sleep when the battery runs out.

so the suspend is based on %, but here we go showing time.

> Monitoring that is not something the user
> should need to do, and that's reflected in the current implementation.

we're not talking about suspend, are we? 

> I'd happily welcome an approach that makes the time reported better though.

... which will never happen as long as it's "close to almost broken but not 
quite". for those of us who it's broken for (regardless of drivers) we won't 
use it. the rest of you will. feature remains braindamaged.

still, a long term usage heuristic would likely be more accurate, but unless 
it can predict my behaviour and what the computer will choose to do next .. 
good luck.


let me close with an example from the world of automobiles: ever notice how 
fuel gages show "how much is left in your tank" versus "how many kilometers 
you have left to go"? think about it. this is the exact same issue. now, 
either car manufacturers are simply overlooking an obviously great feature 
that would be trivial to implement in today's cars or we're doing something 
really stupid here.

i'm guessing car manufacturers realize that it's safer to let the user guess 
based on the readout of the fuel level, their expected use of the car and 
their experience with that vehicle than leave people stranded and surprised 
because the car said it had 10 more kliks right before hitting an uphill 
incline.

-- 
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/20090514/ef5b4ea9/attachment-0001.sig