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.
If you're a button, you have one job
221–230 of 308 posts
Re: If you're a button, you have one job
#222Earlier 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
[1] https://web.archive.org/web/20220418124401/https://techland....
Re: If you're a button, you have one job
#223Earlier 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.
Re: If you're a button, you have one job
#224Earlier 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.
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
#225I'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…
Re: If you're a button, you have one job
#226Earlier 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.
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
#227I 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.…
Re: If you're a button, you have one job
#228One 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
#229Earlier 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.
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
#230Earlier 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…
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.