Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Buttons as Finite Automata

web.stanford.edu

Post reply on HN
Print view View original

51–60 of 82 posts

Re: Buttons as Finite Automata

#51

Post by ______-_-______ »

gumby wrote: post #27

What I love about this is back in the archaic days when car radios had (mechanical) radio buttons, that was the introductory example of a tiny state machine. They were also used in other devices but the car radio was the application everybody had seen. Nowadays I imagine only a small proportion of people who deploy "radio buttons" have even seen such a car radio, so the metaphor is now empty, like the floppy disk ico…

Random question, were physical radio buttons ever circular, or are they circular on computers only to differentiate from a check box? I've only ever seen rectangular radio buttons IRL, and a quick image search seems to agree.

https://www.knowahead.in/wp-content/uploads/2012/05/car-radi...

https://41.media.tumblr.com/tumblr_mbyb9qOw8H1rg5mmto1_1280....

https://i.pinimg.com/originals/10/d6/86/10d686376ae39772ac4e...

Re: Buttons as Finite Automata

#52

Post by [deleted] »

p1necone wrote: post #47
zevv wrote: post #18

I am an embedded software engineer, and I love everything about this FSM example. It shows that seemingly simple and binary things often have more complexity then meets the eye. I love using old fashioned finite state machines for implementing all kinds of behavior; if forces you to think about every single state and transition, and it naturally isolates the different cases - basically, it makes it easier to think an…

This isn't quite as impossible as you make it sound. You can certainly make it feel like you have this behaviour by triggering A on release if the button is held for Of course now you have to accept the button doing nothing if it's held for longer than 300ms but shorter than 3s, but making it slowly fill up with another colour or something is probably enough to communicate the long press behaviour.

[deleted]

Re: Buttons as Finite Automata

#53

Post by tonyarkles »

FabHK wrote: post #29
feoren wrote: post #25

Earlier quoted context omitted.

Click/hold the mouse while outside of the button. Middle-bottom state is hovering over the button while your mouse is down, without having clicked the button. I can see that being useful. However, I can't see why the bottom-left state is ever useful, except perhaps as the only way to get to the "hover, pressed" state.

It is useful because you don't want to fire when you click and hold outside the button, then enter the button area, then release. So, when you release inside the button, you must know whether you clicked inside or outside the button. Thus you need those states. I think.

If you imagine DOM elements as each having a separate FSM and if you consider the possibility of entry/exit actions on each state, "idle, down" in the bottom left could have an entry action that primes the system for drag & drop. Click down outside, release inside is exactly what D&D would have.

Re: Buttons as Finite Automata

#54

Post by gumby »

______-_-______ wrote: post #51
gumby wrote: post #27

What I love about this is back in the archaic days when car radios had (mechanical) radio buttons, that was the introductory example of a tiny state machine. They were also used in other devices but the car radio was the application everybody had seen. Nowadays I imagine only a small proportion of people who deploy "radio buttons" have even seen such a car radio, so the metaphor is now empty, like the floppy disk ico…

Random question, were physical radio buttons ever circular, or are they circular on computers only to differentiate from a check box? I've only ever seen rectangular radio buttons IRL, and a quick image search seems to agree. https://www.knowahead.in/wp-content/uploads/2012/05/car-radi... https://41.media.tumblr.com/tumblr_mbyb9qOw8H1rg5mmto1_1280.... https://i.pinimg.com/originals/10/d6/86/10d686376ae39772ac4e...

I only remember rectangular ones on actual car radios, but on other apparatus they were mostly circular.

Basically a "radio button" interface is a mechanical XOR. So for example to route a signal to destination A, B, or C you'd want to push the A button and be sure B and C weren't selected. Often it mechanically latched, so you could also see at a glance which option was selected, rather than needing to have an indicator (typically a small incandescent bulb).

Radios themselves implemented that mechanism slightly differently. Each button had a stop (like a tab stop, not an organ stop). When you pushed the button it disabled all the other stops and then either a spring pulled the arm right to the stop or your own muscle power pulled it left. A pully rotated the tuner dial as the arm moved right or left. I believe the buttons were rectangular in order to have enough surface area for your finger to supply a firm press enough to pull the tuner arm all the way from right to left (the extrama case). If they'd been round they would have taken up too much vertical space.

The radios typically had five or six favorites, no more. The entire mechanism was mechanical.

Re: Buttons as Finite Automata

#55

Post by caseyross »

What's also interesting to realize is that the standard HTML button is a sort of unholy chimera that doesn't model any sort of physical button in common usage.

Physically speaking, we generally have either:

1. a "push" button, which activates when you press it down fully, or

2. a "hold" button, which activates continuously when you hold it down.

In either case, the "action" occurs at the instant you press the button down, and perhaps continues until you let go.

But the standard HTML button works differently, and from a physical perspective, quite weirdly: when you press it, it only gets "cocked", and when you release it, it activates. That's why its state representation feels complex and unintuitive!

Rather than the behavior of a "push" or "hold" button, the standard HTML button behavior is more like extracting an SD card: you press the card in and then release it to get it out.

(I'm sure there are physical buttons out there somewhere that activate on release. And you can also make a great model of a "push" or "hold" button with custom JS. But I think it's fair to say that the default HTML button doesn't work like real-world experience would lead anyone to expect.)

Re: Buttons as Finite Automata

#56

Post by mirekrusin »

recuter wrote: post #46
atoav wrote: post #43

Earlier quoted context omitted.

You: "So you want action A to happen immediately when the button is pushed AND 3 seconds after that when the button is still held action B should happen?" Customer: "No, I only want action B when it is held for 3 seconds" You: "Todays technology can't do that" Customer: "What. Wait. Why?" You: "Because at the point when action A would be triggered we would have to know the future to tell whether the button will have…

PM: "Let's not rush into any hasty answers!" (Under no circumstances should you show them this: https://www.youtube.com/watch?v=BKorP55Aqvg )

He should be fired for not suggesting 7-dimentional plot.

Re: Buttons as Finite Automata

#58

Post by xsmasher »

recuter wrote: post #46
atoav wrote: post #43

Earlier quoted context omitted.

You: "So you want action A to happen immediately when the button is pushed AND 3 seconds after that when the button is still held action B should happen?" Customer: "No, I only want action B when it is held for 3 seconds" You: "Todays technology can't do that" Customer: "What. Wait. Why?" You: "Because at the point when action A would be triggered we would have to know the future to tell whether the button will have…

PM: "Let's not rush into any hasty answers!" (Under no circumstances should you show them this: https://www.youtube.com/watch?v=BKorP55Aqvg )

This is entertaining, but also cringe; clients and product people aren't generally idiots. They just have requirements that they can't adequately express.

Requirements capture is part of every eng job I've had.

Re: Buttons as Finite Automata

#59

Post by agumonkey »

zevv wrote: post #18

I am an embedded software engineer, and I love everything about this FSM example. It shows that seemingly simple and binary things often have more complexity then meets the eye. I love using old fashioned finite state machines for implementing all kinds of behavior; if forces you to think about every single state and transition, and it naturally isolates the different cases - basically, it makes it easier to think an…

Been reading a few books about automaton (after going back into parsing) and it's indeed nice. There's something universal in them.

Re: Buttons as Finite Automata

#60

Post by recuter »

xsmasher wrote: post #58
recuter wrote: post #46

Earlier quoted context omitted.

PM: "Let's not rush into any hasty answers!" (Under no circumstances should you show them this: https://www.youtube.com/watch?v=BKorP55Aqvg )

This is entertaining, but also cringe; clients and product people aren't generally idiots. They just have requirements that they can't adequately express. Requirements capture is part of every eng job I've had.

I hear you and I understand what you're saying, those are some good points. Can you express what you require out of a none cringe comedy skit that this lacks?
Post reply on HN