I’ve been saving each vote as sort of a trinary variant of Approval voting… capital letter for +1 point, lower-case letter for +0, letter omitted entirely for –1. Originally I had planned on doing regular Approval voting, but Pulsar expressed a lukewarm opinion about option C so I added a state between “approve” and “disapprove”.
Maybe, but it’d add UI complexity that I’m not sure is worthwhile. The ROM is also getting close to full, so I’ve been a bit picky about what I add. I’m hoping it can be decided by vote instead of using most of the remaining space for ramp blink options.
Other things that space could potentially be used for:
Make ramp memory optional? (always turn on at same brightness)
Add a sunrise / alarm clock mode?
Make muggle mode fancier? (simplified ramping or low/med/high or something)
Factory reset function?
Add another “mood” or blinky mode?
Optical programming mode? (configure the light from a web page, like a Lux-RC driver)
Leave room for enabling non-default compile-time options, like dual-switch support?
If I give it weights of (1, 0.5, 0) instead of (1, 0, –1), things might look a bit different:
A: 6.0
B: 11.0
C: 16.5
D: 11.0
Or if those are expressed as a percent of total votes:
A: 31.6%
B: 57.9%
C: 86.8%
D: 57.9%
Perhaps it’d be best to use the percent, and set a threshold for what’s high enough. Like 50% or 66, maybe. The positive/negative weighting kinda implies a threshold of 50, but that might not be ideal.
I would say only add those blinkies that are functional. You mentioned that the pause at B and C are too quick for anyone to respond to stop ramping from going beyond regulation (when ramping up). Therefore I would say it is not functional in the sense that you can actually do something with it, (although it does provide information, there isn’t something you can do about it in the moment. You would have to stop ramping up, and start ramping back down, and stop slightly lower than regulation). Whereas A and D give you a definite indicator - we’ve reached our destination, (programmed or otherwise) - you can now release the button.
You could just program a function that will set the light to the different regulations. It could be another mode, but I would rather have some of the fun functions you outlined above. I like:
“Add a sunrise / alarm clock mode?
Make muggle mode fancier? (simplified ramping or low/med/high or something)”
And I would be happy with either B or C, I normally top off my cells pretty regularly, a blink at either B or C would tell me I have 8hrs or 1hour runtime, respectively.
Weird, off the wall suggestion, would a “max brightness at runtime X” work?
Ie, in a config mode, select runtime required (one click per…half hour? So 5 cicks is 2 1/2 hours), light blinks clicks back as a verification of required time and goes to the brightest output the cell can sustain for that amount of time. A full cell will obviously output more lumens than a 1/2 full cell, but both would run for the same 2 1/2 hours.
I assume uncalibrated voltage measurements from the driver would make this unworkable though.
I vote A and D, especially if auto reverse is implemented. The changes at the extremes are the most difficult to perceive, so I find it useful to know when to let go of the switch.
The mid blinks serve little purpose to me, as mentioned above the ramp rate is so high, it just tells you that you passed the point - like a mile marker that you can’t see until you pass it going 60.