Energy Saving KCM redesign
The Energy Saving KCM has long irked me because:
- In order to see the settings for a single field in different battery modes, I have to switch tabs.
- In order to switch settings for both Battery and Low Battery mode, I have to do it twice. Three times if changing it for all power states including AC. Makes simple changes hard without providing a pro workflow for the customization-overkill power user that really justifies the complexity.
- Each tab is longer than my default window height, and an unsightly mess of unaligned label indentations.
- In addition to the three tabs of Energy Saving, more power actions can be found both in Activity Power Settings and Advanced Power Settings, and again those are disconnected from the settings in Energy Savings in presentation.
So here's my attempt at designing a better UI for the stuff in Power Management.
The first big change is that settings are organized by function, instead of by power state or activity (together known as "Profile", but I removed that term from the UI to avoid clashing with the distinct "power management profile").
The second big change is that there is one field for the default value affecting each Profile. The user and/or default-setting developer can add one or more Exceptions which set a separate value for the same setting under a certain condition. The idea is that I really only want to set my laptop lid actions once, and use the same settings between Battery and Low Battery for the most part. Exceptions can be removed by the user as well; the existence of a few sensible default Exceptions helps with understanding the concept on the fly.
This paradigm has the effect of both reducing and reintroducing some complexity:
- We generally need only one field per setting, instead of properly named checkbox field plus clumsily-labeled "actual settings value" field.
- However, adding an Exception for a given one-liner field will add two extra lines: one for the condition (e.g. "On battery") together with its "minus" Exception-removal button, and one for the value of the setting under that condition. The combination of both lines gets a common form label assigned, named
↪ exceptin my drafts below.
Overall I think it accounts for some good space savings compared to the status quo, but not enough to entirely fit the whole Energy Saving KCM with all of its three tabs into a single page that fits as a whole. So after redesigning the fields, I ended up splitting them into several pages again. I don't think that should be an issue because I get rid of the existing three-page subdivision in Power Management, which is currently "Energy Saving", "Activity Power Settings" and "Advanced Power Settings". Instead, we'd have the following pages below.
All hail ASCII form art!
Brightness
**Laptop Screen**
Screen brightness -------------------------()----------- 70%
↪ except [On battery: ▾] [-]
-------------------()----------------- 50%
Dim automatically [✓] [after 10 min 🡙]
Switch off screen [✓] [after 20 min 🡙]
Exceptions [➕ Add...]
**Keyboard**
Keyboard backlight ----------------------------()-------- 80%
Exceptions [➕ Add...]Default screen brightness goes to Displays & Monitors in addition to here. Default keyboard backlight goes to Keyboard in addition to here. Otherwise the user has to navigate around between different KCMs in order to change related settings. Ideally these KCMs will link to the Energy Saving KCM for dimming settings.
The string "Laptop Screen" is taken from the Display Configuration KCM, which uses it too. I figure if there's no laptop screen or keyboard backlight, the relevant section and possibly the whole page won't be visible.
For the "Add" button, I'm imagining a pop-up menu with a flat list of Exception-capable field names for that section (e.g. the "Add" button for the "Laptop Screen" sction would contain three actions named "Screen brightness", "Dim screen when inactive" and "Switch off screen"). The selected one will then dynamically add this two-line field with ↪ except label.
I tried a few permutations for the UI for the condition+value combo, and ended up on this design. You might wonder why the timeout isn't part of the condition line. One reason is that the condition line needs to be generically applicable to all fields, and timeouts only make sense for some of them. The other reason is that this way we can define a condition as state, as opposed to an event.
Also, it keeps the list of exception drop-down options from exploding - we don't want a timed and a non-timed option for each power state, and I'd rather prefer to avoid an extra "after 0 mins" field for each exception by default.
Furthermore, we could use the global brightness shortcut (and power/battery plasmoid) to also set the KCM settings for the current state, instead of only setting the main brightness but having a profile change reset it again next time. Because we know what state we're in, so we can figure out which particular setting to adapt. With a bit of luck, this might fix some of the funky brightness-setting errors that I've encountered a few times in the past.
Note that an Exception with "On battery" condition also matches "On low battery" if the second one isn't matched by an Exception with higher precedence.
Anyway, enough rambling. More pages, same concepts, no nesting of fields in the form layout (note that I put Exception fields on the same level of the form as well, I think it works, even with a makeshift Unicode arrow to connect it to the label above):
Suspend session
**Suspend Actions**
When laptop lid closed [Sleep ▾]
↪ except [When an external monitor is connected: ▾] [-]
[Do nothing ▾]
When power button pressed [Shut down ▾]
Suspend automatically [Do nothing ▾]
↪ except [On battery: ▾] [-]
[Sleep ▾] [after 10 min 🡙]
↪ except [At critical level: ▾] [-]
[Hibernate ▾] [after 1 min 🡙]
While in Sleep mode [ ] Hibernate after a period of inactivity
Exceptions [➕ Add...]
**When Suspending**
Media playback [ ] Pause media players
[🕭 Configure Notifications...]Media playback here is lifted from "Advanced Power Settings", which allows us to put Battery Levels and Charge Limit into a more intuitively named "Battery Settings" page. Also, I genuinely think it makes a good fit here.
I took the freedom to use "When an external monitor is connected" as Exception condition here. This seems consistent with the theme, avoids a random nested checkbox field and allows more customization if desired, but not sure whether it should only be an option on this page / for the laptop lid action or a generally available condition.
Note that this incorporates the "At critical level" action from "Advanced Power Settings" as a standard condition+action field, with "At critical level" being a newly introduced condition as opposed to the original set of AC Power, Battery and Low Battery.
Performance
Power management profile [Best Performance ▾]
↪ except [On battery: ▾] [-]
[Balanced ▾]
↪ except [On low battery: ▾] [-]
[Power Save ▾]
Exceptions [➕ Add...]This one was hard to decide, because three separate fields are easy to add (AC, Battery, Low Battery) but then it wouldn't be consistent with any activities added subsequently. It would be straightforward to hardcode/repeat the fields for each power state and activity, but then one would have to select the same state several times and it's still not clear/configurable whether the activity has precedence or the power state. So I'm going with the same Exceptions concept here as well.
One thing this proposal isn't 100% clear about is precedence of exceptions. Given the above examples, it's clear that there can be an arbitrary number, also I established that the condition drop-down allows a free choice of available conditions. (At least the conditions that haven't already been used above or below for the same setting.)
So one could pick implicit precedence (e.g. low battery always gets chosen before regular battery) but then activities must take precedence before any power states, and that's a little limiting. The order of "except" fields seen by the user doesn't match the programmatic order in that case.
Or one could pick precedence as listed in order and check conditions from the bottom-listed field to the top (default) one, and that makes sense when reading, but users could easily end up with unexpectedly broken setting when selecting exceptions in the wrong listed order. If using order as precedence, should there be up/down buttons next to the "minus" button for removal? Or a "Rearrange" button next to "Add"? Perhaps when selecting a power state, the logic could make sure that AC power is always listed above battery and battery is always listed above low battery, and leave the rest to fate and the user? Not entirely sure about this, but I feel like it's a solvable issue.
Wireless connections
Wi-Fi [Leave unchanged ▾]
Bluetooth [Disable on battery ▾]
Mobile broadband [Disable on low battery ▾]Breaking with the theme, I left out Exceptions for this page because it seems more confusing than beneficial. I guess people might want to enable/disable wireless connections when switching between activities, but is it a strong enough use case to make this form more complicated?
Run scripts
Before suspending [_______________________________________] [🗁]
After waking up [_______________________________________] [🗁]
Trigger [On AC Power ▾] [after 0 min 🡙] [-]
Script [_______________________________________] [🗁]
[➕ Add...]Pressing the "Add" button will add another Trigger/Script pair here, without pop-up menu because there's only one possible thing to add on this page. Other selectable values for the Trigger drop-down include "Leaving AC Power state" (likely with timed delay disabled) as well as analogous "In activity" and "Leaving activity" options.
I did put the timeout next to the power state on this page (goes the same for activities) for two reasons. One is that this page is for power users who can bear a little information overload. The other is that unlike on the remaining pages, the Trigger here is not a state but an actual event. It has to be an event when a script is run. That's different than a settings value that should be deterministic and repeatably applicable at any time.
Battery Settings
**Battery Levels**
Low level [15% 🡙]
Critical level [ 3% 🡙]
**Charge Limit**
Keeping the battery charged 100% over a prolonged period of time may accelerate
deterioration of battery health. By limiting the maximum battery charge you can
help extend the battery lifespan. (verbatim from "Advanced Power Settings" KCM)
Stop charging at [80% 🡙]
Start charging only once below [70% 🡙]This is just the remainder of "Advanced Power Settings", minus the relocated "Other Settings" section and thus renamed.
I'll leave it like this for now and put it up for discussion. Thoughts, objections, suggestions? Did I perhaps miss someone else doing much of the same work already? Should I have consulted with the VDG first, or is this the way to do it? Am I completely off base for one reason or another? Is this kind of design useless without actually sitting down and implementing it? Tons of questions, and I'm sorry if I perhaps approached it in the wrong way. Gotta use the inspiration when it strikes.
Note that I'm a lazy fuck and might not reply or revise on time. If it helps, feel free to take ownership of this ticket at the right time. Or close it if it's useless, and reuse it elsewhere in a different form. Hopefully it can evolve into something useful eventually.