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

If you're a button, you have one job

unsung.aresluna.org

Post reply on HN
Print view View original

201–210 of 308 posts

Re: If you're a button, you have one job

#201

Post by pixelatedindex »

port11 wrote: post #110
embedding-shape wrote: post #53

Earlier quoted context omitted.

I'm no longer the Apple/Mac/Jobs fan-boy I once was in my earlier days, but I do miss the Apple presentations that felt like they were run by a human being wanting to show off cool stuff. I couldn't even finish the last Apple presentations as it all feels so stiff, inhuman and run by suits, they all seem like robots scared of diverging from the holy script who will get fired if they display emotions and humanity. Off…

The scripted talks in front of fancy backgrounds do make it unpalatable, it’s just a fancier version of corporate slideshows. I suppose trillion-dollar companies aren’t as willing to take risks.

> I suppose trillion-dollar companies aren’t as willing to take risks.

Which to me makes no sense, surely you have some budget for risks if you are a 1T company? I suppose their risks are more moonshots to some degree like the Apple Car but nevertheless, I do miss the old presentations.

Re: If you're a button, you have one job

#202

Post by jrm4 »

I have a related cybersecurity point.

No interface should, on a regular basis, contain buttons that, if pressed -- harm the computer and other computers near it.

And of course, this is links in modern email.

Re: If you're a button, you have one job

#203

Post by budman1 »

crote wrote: post #127
inigyou wrote: post #114

Earlier quoted context omitted.

They didn't say how often the reads are - 50 reads could be only 5ms.

In practice switch bounce often lasts tens or even hundreds of milliseconds, and you need to space out the read process to cover the entire bouncing process if you want to avoid registering fake presses. Using basic averaging means your minimum input latency is going to be ~half your bounce time - which is often way too high for it to feel like real-time input. If you want to achieve low-latency input, "act on first…

the cheaper the switch, the longer the bounce.

Re: If you're a button, you have one job

#204

Post by calvinmorrison »

bloak wrote: post #50

I used to have a device with a physical button which, when you pressed it, would beep and add 30 seconds to the time. However, sometimes it would beep and not add 30 seconds, and sometimes it would add 30 seconds without beeping, so you always had to squint at the dim display to discover whether it had worked or not. I thought this must be a peculiarly bad design ... but since then I have lost count of the number of…

Another one I see is low end devices have a volume knob that instead of being a potentiometer are a rotary dial encoder so you end up usually only being able to adjust the volume as fast as it's sampled, which is slower than you want for example in traffic turning the radio down to hear stuff

Re: If you're a button, you have one job

#205

Post by mrkeen »

inigyou wrote: post #160
mrkeen wrote: post #145

Earlier quoted context omitted.

I call it the "doing two things" problem. Your write imperative code, which issues two commands, both of which can fail independently. There are plenty of ways to pretend to 'deal with it'. Firstly it will just pass all tests, so most devs can stop thinking about it right away. A dev might think you can just catch and log the exception. Doesn't fix it. You could run the code in prod for a while, see if it goes wrong.…

Why can the two things even fail at all?

This is not a bad question!

If you flip it and instead ask "how do I write something that can't fail?" you might find some interesting ground.

The best things I know about are static type-checking, pure functions and totality. Different languages provide more or less help with these things. It's perfectly fine to do 'two things which don't fail or cause other things to fail'.

Forgive the digression, but there is an 'infectious' aspect to the above 3 things (see the function-colouring problem), e.g. you can't build pure functions which call non-pure functions. The Dependency Inversion Principle (of SOLID) gives some help in how to tackle this.

Also, the above things only work within one node (of a distributed system).

For multiple nodes, I use something like Kafka, where you write down one event, and have two systems subscribe to it, each doing one thing. Yes, there's still the obvious issue of them failing independently, but when that happens, you have an authoritative source of truth (in the form of Kafka events). This beats the craps out of developer logs.

You skip the laborious questions of "what happened in the system?" and "what should the correct state be?" Because the events are already the answer - just eyeball them.

Events also machine-readable, so if you diagnose a problem and a fix it in one case, there's a good chance you can build a detector for other cases. You don't have to wait for a support ticket to get escalated to the dev team.

You also divide the debugging space dramatically. If the Kafka log says one thing {Bob bought Minecraft for $10}, then the Ownership service is just wrong if it says Bob doesn't own Minecraft, and the Finance service is just wrong if it doesn't report the $10. Fix each independently. At no point do you need to look at Ownership and Finance together to see which one failed halfway through talking to the other, because they don't talk to each other.

Lastly, events are verifiable; they are their own audit trail. If your boss asks how much money is in the system, would you feel more confident reporting whatever the current balance is set to (i.e. the outcome of whatever code executed the last "UPDATE Balance ..." statement, or would you like to be able to sum over every transaction that you ever recorded?

Re: If you're a button, you have one job

#206

Post by CWuestefeld »

I want to support the "what about debouncing" argument mentioned elsewhere; the author shouldn't just ignore this.

But I also hate the "you had one job" meme and want to argue against its mindless usage. Most of the time, when people do the "you had one job" thing, it's false. And that's true most of the time in the case of buttons, too. In a typical user interface, a given button has some combination of these jobs:

* Communicate what action will occur should the button be pushed.

* (Sometimes) communicate the current status of some aspect of the system (e.g., often a button is used to enable/disable a mode, and the button itself visually conveys what the current mode is).

* Execute the intended action upon clicking.

* (Sometimes) communicate that the command has been received and is being executed (e.g., in the OP, the button might disable itself while animating the rotation in order to avoid the confusion the OP complains of).

Re: If you're a button, you have one job

#207

Post by mathgeek »

CWuestefeld wrote: post #206

I want to support the "what about debouncing" argument mentioned elsewhere; the author shouldn't just ignore this. But I also hate the "you had one job" meme and want to argue against its mindless usage. Most of the time, when people do the "you had one job" thing, it's false. And that's true most of the time in the case of buttons, too. In a typical user interface, a given button has some combination of these jobs:…

Your points are good ones, especially since they emphasize that different people have different expectations of what a "button" is and isn't. Your points individually describe a button with a label, one with a toggle, an actual button, and a progress indicator. All of those things can be "buttons" depending on the user.

Re: If you're a button, you have one job

#208

Post by xorcist »

darkwater wrote: post #77
hypfer wrote: post #56

Earlier quoted context omitted.

Speaking entirely out of my ass here: FOMO for sure is one of the driving factors. "We cannot risk looking outdated". So weak management, probably. But also talent availability I suppose. If there's a new trend, the pool of people you can hire include many that are in on that trend. UI frameworks too, probably. The modern thing™ does the modern thing™ and you do want to be on the modern thing, because you fear that o…

If UIs today still looked exactly the same as Windows 2.0 or System 7 or CDE people will be bored to death. Aesthetics come and go and come back, it's part of how humanity worked for a few centuries already.

Why do people say that? I am not bored by my Braun alarm clock, neither by my Singer sewing machine or my De Buyer cookware. Why would I be bored by well executed digital desktop designs such as BeOS, AmigaOS or even Windows 2000?

Re: If you're a button, you have one job

#209

Post by elxr »

Telaneo wrote: post #87
xigoi wrote: post #54

Earlier quoted context omitted.

What’s wrong with flat UIs? Skeuomorphic designs have served their purpose of helping people get used to computers, but now that is no longer necessary.

New people are born every day.

And? What does that have to do with the merits/downsides of flat UI?

Re: If you're a button, you have one job

#210

Post by elxr »

tomasphan wrote: post #167
crewindream wrote: post #120

Earlier quoted context omitted.

I have only iphone, but from my experience, apple ui quality is just a huge myth nothing to do with reality. On average it is has same amount of crappy UI experience, just in different places.

How can you compare if you have only iPhone?

Because the iphone can run apps made by people other than apple.
Post reply on HN