battery plasmoid and remaining time..

[Celeste Lyn Paul]

Hi all,

When Zack calls, I answer (Sebas poking me helps too ;). I've read through 
most of the thread and want to provide my .02. Let's begin by breaking down 
the problem a bit.


Purpose of the battery widget:

* Provide a visual indicator of the current power status (battery or AC power)
* Provide a visual indicator of the amount of battery left
* Provide access to more detailed information about the power status (most 
notably battery details)
* Provide access to other configuration functionality such as power profiles, 
suspension, etc.

At-a-glance information about power remaining is provided by the widget icon. 
This particular discussion is about the access to more detailed information, 
such as percentage/time remaining until the laptop dies. Users want to know 
this more detailed information in order to do "planning" away from a power 
source. 


Common use cases:

* Aaron wants to know how much longer he can sit at the cafe
* Chani wants to know if she has enough power left to take her laptop to class
* Zack wants to know how many episodes of The Family Guy he can watch on the 
flight home


Design Problem: 

* Power estimations have a number of problems because they are dependent on 
hardware working/reporting properly and other usage factors such as CPU use, 
wifi use, disk access, and monitor brightness.
* The time value reported through the widget is often grossly incorrect and so 
the question of "why report it at all" was brought up. The proposal was to 
report percentage only. 


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. They just want to know how much 
longer until they need to shutdown/plugin.
* Lithium ion batteries degrade over time, so even if you knew what your 
battery capacity was when you purchased the machine, it probably isn't 
accurate now
* Reporting percentage seems to be pretty useless when it matters. What 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, 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.


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?


Questions:

* How many of the hardware/driver related problems can be fixed? Is this 
difficult/impossible and should we continue with the assumption that calculating 
power consumption will always be grossly inaccurate?
* What is the extent to the "grossly inaccurate time reporting" issue? Is it 
only with some hardware, much hardware, most hardware?


My thoughts:

* I really believe that only reporting percentage is not enough to meet user 
needs. Even if it is inaccurate and mostly a guess we should find a way to 
provide a better time estimate.
* What is reported will always be inaccurate and the best we can hope for is 
"close enough", but always erring on the side of caution.
* 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.


My Argument:

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. 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. This is silly -- we shouldn't be making the user do work 
the computer can do. If estimating time is inaccurate then we need to find ways 
to fix it and make it more accurate, not remove the problem. 


Design Ideas:

* We should aim for creating a more sane estimate than directly reporting 
information
* Instead of using current usage to estimate time, can we collect trend data 
to estimate a more accurate value? Instead of polling the current state, we 
could look at the past 10 minutes to see if Or would this cost too much?
* 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?
* What about an artificial range imposed on whatever is reported? If the system 
reports 1h 30m left, can we +-n to give the user the impression of an 
estimate? If the user understand it is an estimate, then the cost of an 
inaccurate estimate is reduced.
* 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? It would 
inform the user of their current power consumption condition and educate them 
about how time remaining can fluctuate and depends on these things.


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

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

Thoughts? Comments?



-- 
Celeste Lyn Paul
KDE Usability Project
usability.kde.org