battery plasmoid and remaining time..

[Eduardo Robles Elvira]

On Fri, May 15, 2009 at 6:14 AM, Zack Rusin <zack at kde.org> wrote:
> On Thursday 14 May 2009 23:22:46 Chani wrote:
>> > > It's not made up, as far as I can see it's remaining capacity / current
>> > > discharge rate. So it does tell you when your battery runs out if you
>> > > keep doing what you're doing right now.
>> > >
>> > > Maybe a good point is to think about how we can make this more clear to
>> > > the user.
>> >
>> > I'd suggest prefixing that number with an icon of a dude going "3
>> > hours... no, 2 hours! no! 1:30! no 6 hours! oh, for gods sake, i give up"
>> > and then an animation of him throwin his hands up in the air. that'd
>> > pretty much express exactly what it's doin.
>>
>> "four hours and ten minutes! four hours and eight minutes! four hours and
>> fifteen minutes! four hours and five minutes!"
>> who cares, at least I know I've got around four hours left.
>> I don't know what sort of hardware you've got, but my battery doesn't vary
>> that wildly. I managed to make it go down from 4:20ish to 3:50 by starting
>> a compile, but that's as much as it's jumping.
>
> nope, that's crap. if *you* don't see a huge difference between idle processor
> and a movie playing/compile/gamin then it's your hardware that's shite. or do
> you actually think that all those patching of all the apps to not run extra
> timers was to save a minute or two?
>
>> > of course that's also what "2 hours left" can mean.
>>
>> if that's true then your hardware *sucks*
>
> nope, as noted above it's your hardware that sucks if that's not the case. an
> idle 13" laptop with no usb pollin devices should be takin about 10Watts.
> lowerin the screen brightness to maximum will win you a few watts as well.
> playin a full screen movie, compilin, playin a game, etc it will likely jump
> to 20Watts+. if you don't see that then your acpi setup is busted. so we're
> talkin about hours of difference (especially for people with larger batteries).
>
> as to the rest, it's about feelings, which honestly is a shite discussion to
> have in a context of a development list. my point is "it's wrong to have a
> computer guess/lie", yours is "but it's nice!", which is a discussion no one
> can win. as i said in my last email "if we only had like, i don't know, a
> 'usability team' to look at those issues!".


I've just read the whole discussion, and this is my point of view on all this:

* Most users will find useful an indication of how much time is left
in a device which has only some hours of battery such as a
laptop/netbook. I could be optional, but active by default.

* It's difficult to calculate accurately and we cannot predict the
future, and some devices are broken. But if we relay on recent battery
usage and percentage of battery left, which I've experienced both are
fairly accurate measures, we can guess the future usage and get a good
enough predictions for most of the time. You've been using 10W+-2W for
last 10 mins, and in 10mins the battery has decreased  2%. We can
predict that if the battery usage continues that way and the battery %
decreases linearly, you've got X mins left. when we have less than X%
of battery, we can be warier and tend to worst-case scenarios just to
play it safe.

An use case scenario: some background process  - cron, nepomuk, amarok
indexing, whatever - rises the battery usage to 17W, well then what we
do?  when usage changes enough we can tell the user somehow. For
example we have a visual indicator in the battery plasmoid for the %
of battery left, and we have a yellow ray at one side which moves from
there when we don't have the plug connected. we could reuse that ray
to somehow hint if the battery is being consumed faster than recently
predicted (a more obvious ray, perhaps a redder ray if consumption
rate rose?), readjust the prediction and flash "1h left" on the top of
the applet. This flash feature needs to be enough for the user to
notice it but be not so prominent as to be able to ignore it easily
too (just a good compromise), and should only be used when battery
consumption rate changes enough to be noticeable time-wise.

Some people have suggested using normal-case and best-case scenarios,
something which is becoming much more useful in devices in which
battery draining can change from 10-W to 20+W depending on level of
CPU/USB/monitor/etc usage. We could make that an option, and let the
packagers make it default or not depending on the distro (if someone
is using plasma in n810 it's more likely they want that option active
by default) or directly the hardware. Anyway with the  "battery
consumption rate changed flash" described above, that might be less of
a problem.

Just my 2ct.