Yeah, too complicated for the low-price brief, that’s for sure.

Your way is better, especially since I’ve remembered that rocker switch mechanisms are available in on-off-momentary arrangements too

Phlogiston wrote:

Yeah, too complicated for the low-price brief, that’s for sure.

Your way is better, especially since I’ve remembered that rocker switch mechanisms are available in on-off-momentary arrangements too

Yeh, anyone who has power windows (or locks) in a car has seen a switch that’s center-off, momentary-up, momentary-down.

Lightbringer wrote:

Phlogiston wrote:

Yeah, too complicated for the low-price brief, that’s for sure.

Your way is better, especially since I’ve remembered that rocker switch mechanisms are available in on-off-momentary arrangements too

Yeh, anyone who has power windows (or locks) in a car has seen a switch that’s center-off, momentary-up, momentary-down.

I concur.

Remember, you’re talking about something intended to be assembled chabuduo by Chinese workers” from cheapest-source part suppliers.

Quote:

If you are German or Northern European in general, you are likely used to things being done according to specifications and high standards. You probably wouldn’t expect less than 100%. As an American, you are may be used to a little more wiggle room. Not everything is quite as perfect, for example with regard to workmanship, but still very good, like 90-95%.

Not so in China. In China, the typical approach is summed up in one word: “chabuduo”, meaning “nearly” or “almost”. For most Chinese it also means “good enough”. You will hear this term a lot.

KISS. You need this to be far simpler and more robust than you want to imagine, to take up the slack.

Just ask VOB about his new motorcycle…

No bearing spacer? Rear wheel locks up? No problem!

Good thing flashlights aren’t life safety critical.

Oh, wait ….

I have a feeling that my flashlight UI designs aren’t very well aligned with the popular opinion, but Artur asked me to weigh in so here’s my input. This interface setup is what MELD uses in lights with dual switches:

The only difference between the two switches should be that one is for UP and one is for DOWN. Any user input that could have directionality will follow the UP/DOWN designation of the switch that is being used. For any other user input, both buttons should function exactly the same.

For example, here’s a simple ramping UI with dual switches that follows this philosophy:
Click either button to turn on. Click either button to turn off. Press and hold either button from off for momentary usage. While on, hold down either button to ramp; UP button goes up, DOWN button goes down. Double click UP switch shortcuts to max; double click DOWN switch shortcuts to min.
This can be extended to further functions with extended commands (triple click, click-click-press, press both simultaneously, etc.). In any case, a command that doesn’t have any up/down association (on/off, battery check, options menu, etc.) doesn’t matter which switch is used, they both act the same. Any command that does have an up/down association (ramping, shortcuts to high or low, advance through menu options, etc.) will choose the direction based on which button is pressed.

tterev3 wrote:

I have a feeling that my flashlight UI designs aren’t very well aligned with the popular opinion, but Artur asked me to weigh in so here’s my input. This interface setup is what MELD uses in lights with dual switches:

The only difference between the two switches should be that one is for UP and one is for DOWN. Any user input that could have directionality will follow the UP/DOWN designation of the switch that is being used. For any other user input, both buttons should function exactly the same.

For example, here’s a simple ramping UI with dual switches that follows this philosophy:
Click either button to turn on. Click either button to turn off. Press and hold either button from off for momentary usage. While on, hold down either button to ramp; UP button goes up, DOWN button goes down. Double click UP switch shortcuts to max; double click DOWN switch shortcuts to min.
This can be extended to further functions with extended commands (triple click, click-click-press, press both simultaneously, etc.). In any case, a command that doesn’t have any up/down association (on/off, battery check, options menu, etc.) doesn’t matter which switch is used, they both act the same. Any command that does have an up/down association (ramping, shortcuts to high or low, advance through menu options, etc.) will choose the direction based on which button is pressed.

Interesting light but from my point of view:

- UI is too complicated
- I fear that too much features might compromise the reliability
- it will not be a budget light
- it might end up bulky
- we might not see this light before a long time

Just my 2 cents. I know I will still buy it if it’s not too expensive.

tterev3 wrote:

I have a feeling that my flashlight UI designs aren’t very well aligned with the popular opinion, but Artur asked me to weigh in so here’s my input. This interface setup is what MELD uses in lights with dual switches:

That would rock my ‘fro, yes.

rost333 wrote:

I think we will stay with solution from post #89

Hi mate! Sorry, didn’t have the chance to answer your PM yet

However, I guess I will forget my options and look at this suggestion :

tterev3 wrote:

[…]For example, here’s a simple ramping UI with dual switches that follows this philosophy:
Click either button to turn on. Click either button to turn off. Press and hold either button from off for momentary usage. While on, hold down either button to ramp; UP button goes up, DOWN button goes down. Double click UP switch shortcuts to max; double click DOWN switch shortcuts to min.

This can be extended to further functions with extended commands (triple click, click-click-press, press both simultaneously, etc.).

This seems to me as a very good solution!

Please note that my opinion doesn’t disregard the your options posted before. However, it seems to me that for a dual light switch it may be reasonable to consider!

When I have the right time, I will answer your PM Sorry for the delay!!

I like the vast difference between the various UIs being proposed. However, I can't really find myself getting behind UIs that make extensive use of press-and-hold as an action, or that rely heavily on "click X times" as a meaningful interaction. 

I think the UI mentioned and compared to MELD was pretty interesting. One of the first UIs I thought up, when addressing this light, had about half of the base concept the same: Both buttons do the same thing. In my case, I was building around each button controlling a separate emitter, which was pretty neat and led to intuitive interactions once you understood the basics. 

As far as the UI most recently proposed by Rost in post 89, I don't think it would be something most people can just pick up and use. Sure, it would probably be easy enough for someone who read the instructions, but that's not the same thing as intuitive. 

It needs to pass the Enderman’s Gramma test.

Or easiest of all, a magnetic slider with nigh infinite brightness levels…

I don’t see any reason not to use buttons. I understand that you want to make this light stand out from the crowd, but going against too many conventions at once is a great way to add complexity,create issues, and alienate any potential buyers.

Hey, buttons are great, and can be made perfectly waterproof (see the Sofirn/Wurkkos SD05 diving light).

Problem is, ask 20 people here for opinions as to the greatest’n‘bestest UI to use for ‘em, and you’ll get 38 different answers.

So then you get some frankenUI grab-bag of options from the mfr that everyone hates.

Quote:

greatest’n‘bestest UI

Make it with contact pads for Pogo-Whatsis flash connections and sell a modders’ kit for UI changes.

rost333 wrote:

Would it be possible? How much would it cost?
Maybe Sofirn could stand out from the crowd by allowing users to customize the UI in most of their lights?
Those are questions to Sofirn.

Ideally I see a PC program and USB-pogo cable set.
User is turning on the program, connects the flashlight and is able to choose the number of lumens on each brightness level and number of levels.

I’m lacking needed skills but maybe there is a good soul on this forum that could help create such a program and Sofirn could deliver the rest?

Quote:

Then you can use the light

ZozzV6 wrote:

Or add a bluetooth IC and make IOS and Android downloadable app to config the light.

Hm? How’s a BT signal supposed to get in/out of a Faraday-cage of an all-aluminum flashlight?

Lightbringer wrote:

ZozzV6 wrote:

Or add a bluetooth IC and make IOS and Android downloadable app to config the light.

Hm? How's a BT signal supposed to get in/out of a Faraday-cage of an all-aluminum flashlight?

Same way the iPad does: Go out through the bezel around the screen!

What's that you say? You don't have a flashlight with a retina screen? What about a $999 flashlight stand?

I'm sorry I'll go stand in my corner

Mmmmmm, no.

Figure the tube is all Al. The reflector is likely Al as well, only thing left is the tailcap if any, and dunno how small a BT antenna can be made, and it’d play Hell with reliability anyway as well as need a coaxial tube like the FW3A to pass the signal along.

Lightbringer wrote:

ZozzV6 wrote:

Or add a bluetooth IC and make IOS and Android downloadable app to config the light.

Hm? How’s a BT signal supposed to get in/out of a Faraday-cage of an all-aluminum flashlight?

I also like Lupine headlamps setup application.

1stein wrote:

Quite sure the more people involves, the more options we’ll get. But let’s take a wider look. Assuming the Authors aim in creating an over – time classic, widely accessible and for many applications. Shouldn’t we think of ‘the market’? I don’t think (with all due respect) BLFers are a representative group. We’re all crazy about flashlights. To make it right, the Authors should ask a question, who is the potential customer. Let’s say it’ll be very lucky at BLF and sells in number of 1000. And then what? Mugles who bought are likely to return due to too complicated UI. Why not to use advanced processor and program it (flash the bios) just before sending? The same way we choose led temp. or ref type, we could choose software. Like at MTN. This way the light could reach more people, be more flexible and satisfy each group. Moreover, modding this light could be extended by multiple software versions. Anyway, I think the success of this light depends on its sales. BLF won’t bring more than 1000? But if it becames common at gas stations.. BOOM,millions…. So… The software could be developed, best if market research could prove which exactly functions are desired most by a regular buyer. Who that buyer is (statistics on many factors) etc…

A programmable driver is cool. The default UI is for muggles and if Flasholics want it with customized UI, sofirn can program it before shipping. Or you program it yourself.
But I don’t know how to fulfill it and how difficult it will be.

tterev3 wrote:

I have a feeling that my flashlight UI designs aren’t very well aligned with the popular opinion, but Artur asked me to weigh in so here’s my input. This interface setup is what MELD uses in lights with dual switches:

The only difference between the two switches should be that one is for UP and one is for DOWN. Any user input that could have directionality will follow the UP/DOWN designation of the switch that is being used. For any other user input, both buttons should function exactly the same.

For example, here’s a simple ramping UI with dual switches that follows this philosophy:
Click either button to turn on. Click either button to turn off. Press and hold either button from off for momentary usage. While on, hold down either button to ramp; UP button goes up, DOWN button goes down. Double click UP switch shortcuts to max; double click DOWN switch shortcuts to min.
This can be extended to further functions with extended commands (triple click, click-click-press, press both simultaneously, etc.). In any case, a command that doesn’t have any up/down association (on/off, battery check, options menu, etc.) doesn’t matter which switch is used, they both act the same. Any command that does have an up/down association (ramping, shortcuts to high or low, advance through menu options, etc.) will choose the direction based on which button is pressed.