Live data from Hacker News

If you're a button, you have one job

unsung.aresluna.org

221–230 of 308 posts

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

#221
post #197

Earlier quoted context omitted.

Wild take. They’re not born “used to them,” so at some point they quite literally need to get used to them…

The point is that a computer will just be another thing for them to learn, not a replacement for other tools they’ve been using for tens of years. Therefore, the computer does not need to look like those other tools in order to make sense to them.

The fact that the people learning it will be younger is not a reason to make it harder for them to learn. The computer doesn't need to look like other items out there in the world, but it sure is helpful, even if only so you have a reference to explain things from, and so that the iconography is somewhat consistent.

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

#222
post #176

Earlier quoted context omitted.

The original GUIs were all flat because that was the default. A button was a rectangle with text in it. A checkbox was a rectangle with or without an X across it. Pure black on pure white, no colors or shades. Windows used this style until Windows 95. Nobody seemed to have a problem with it. It was largely clear what was a button and what was a checkbox. In hindsight it was certainly uglier than the 95 style (maybe j…

I might be misunderstanding what you're saying, but: In the PC space, Windows 3.x definitely had some skeuomorphic elements. This presents most-commonly with the minimize and maximize buttons[1]. We have to go all the way back to Windows 2 in before we find flatness. [1]: https://archive.org/details/msdos_win3_1

And Windows 1 and 2 were barely even used. Windows 2 sold less than 2 million copies. Windows 3 and co sold 7-ish million. Windows 95 sold more than 40 million.[1] There's a lot less people to complain about Windows 1 and 2, and those people were probably a lot more experienced in the first place.

[1] https://web.archive.org/web/20220418124401/https://techland....

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

#223
post #108

Earlier quoted context omitted.

>averaging the last 50 reads and wait till the majority is either off or on. This is a bad way to do it because it adds avoidable latency. A moving average is a low-pass filter. The switch bounce is better handled by hysteresis. Change state as soon as you see an edge, then ignore further edges until a timer expires, e.g. 5 ms, which should be enough for the bouncing to settle. A 5 ms timeout limits your repetition r…

Lots of replies with good ideas here. The biggest question is that EMI resistance; do you really need to ignore brief closures? In the vast majority of situations, the answer is no.

Yes, you need to deal with EMI and static bursts on your microcontroller inputs.

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

#224
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.

For some of us, the OS isn't a fashion statement, but rather a tool which is to be used to achieve other goals. It shifting around and changing its look is in fact a downside in that context.

I don't think I know any non-tech people who like things changing about. Some tech people like that (I don't), but for the non-techy, it's just another thing they have to relearn for no good reason.

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

#225

I'm sure it just my personal preference but I hate animations. Most often they do little other than slow an application down i.e. the code of the application could finish the task almost instantaneously but for the sake of appearance, they make it take longer to finish. I would much prefer no animations in applications. If the animation is there to disguise some actual slow response, just let me wait, give me jarring…

Some years ago, I attended an informal demo of some application we built. The engineer who had worked on the UI was showing an animation of the initial splash screen. It was only 5 seconds or so but I asked him whether there was an option to disable it. He said there wasn't. I then asked if he didn't think that a user, running this many times, was going to get very tired of seeing it run every time and want to just show the home window immediately on start. I said I knew I would. I told him that regardless of how "cool" it looked, when you see the same thing a few times, it can become annoying leaving the user pissed off because its out of their control. I don't know what happened after that. Since I didn't have any authority to request changes, I was probably ignored.

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

#226
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.

> people will be bored to death

As opposed to what? Be entertained by all the bells and whistles of modern operating systems that have practically unusable user interfaces?

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

#227
post #145
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…

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.…

[deleted]

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

#228
If the ui calls for it I take the current position of the element and the destination then change the current to be exactly in between repeatedly on a interval. That way it moves really fast and eases into position.

One more ancient trick: back when computers were slow I would always ask myself why the data is not already in the desired format.

For example: Today you might have data in a json and turn it into a row of divs. You could store the data as a file with a row of divs which would make it a pain working with it on the backend. But on the front end you wouldn't have to parse it.

The phone doesn't modify the image but it changes the image orientation.

This is much faster but all other operations would need to work with it and when eventually served in a browser all the 100 000 viewer clients would have to rotate it themselves.

I won't argue it's wrong but it shifts complexity from image rotation to image editing and viewing.

It seems strange to add "real" rotation to the ui but the phone app is the industrial standard for image editing.

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

#229

Earlier quoted context omitted.

Wild take. They’re not born “used to them,” so at some point they quite literally need to get used to them…

Yes, but they'll be doing it between age of 2 and 7, not 20 and 90.

Have you tried teaching kids (or just people in general) abstract concepts? Even maths is taught to kids in terms real world items and reasonable actions you can perform with them (you have 5 friends and 25 cookies, how many cookies does it friend get if you give each friend the same number cookies?).

The more you can ground what you're teaching in real world terms, the easier it is to teach. And in the moments where it does deviate from real world conditions, that's where it becomes harder to learn, since now you have to remember exceptions in behaviour compared to what you already know.

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

#230
post #174
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.…

> A dev might think you can just catch and log the exception. Doesn't fix it. You've just succinctly made the argument against checked exceptions FWIW (which I agree with you on). Anyone who has used Java in anger (is there any other way?) will be familiar with: try { doSoemthing(); } catch (CheckedException e) { logger.error("Didn't work", e); } Fault tolerance is general is terrible in most software. One of my bigg…

> It can get a lot worse than that too. I have an app on my phone that will log me out and force me into a 2FA cycle if it hits a network timeout.

I use some fairly popular (in the MSP space) backup software that thinks the network is infallible. The worst case I’ve seen is when it fails on a network request, doesn’t retry adequately, and incorrectly logs the error as data corruption.

Post reply on HN