141–150 of 308 posts
My wife is a behavior analyst and I’m a game developer. We both watch people and try to figure out how why they are doing stuff and how to get them to do what we want. One thing I learned from her is that if you want someone to stop doing something you don’t punish them, you ignore them. No response.
Earlier quoted context omitted.
They aren’t purely for that, they also contribute to how an application feels to use in a creative manner.
I don't want my image editor to feel like something in a creative manner though. I want it to rotate an image by 90° when I tap the button that does that. See, this is exactly my point when I say that animations are no end in themselves. They serve a supporting role to better get the actual job done. The actual job is not "feel" it is "do". For vibes, there are movies, Art, and AI hallucinations. Of course, "feel" ca…
It's not a debate. If you are making app to do something, "form follows function " is always the right choice. If anyone on UI/UX team tells you different you should fire them, they are not interested in making good UIs. If it comes out ugly, well, you need to get good at making useful stuff also look nice
"form over function" only applies to stuff that is looked on more than used by overwhelming degree. Any other case is just someone using it as excuse for them being shit at producing useful stuff that also happens to be beautiful
I assumed that issues like "tap eight times for a no-op" not working was because of software patents not allowing the developer to do the obvious thing. Is that not the case?
Software patents? Care to elaborate?
That said, I can't seem to find any evidence of this particular thing being patented to support my case, so it's probable that I'm wrong.
It's interesting that old Windows apps would accidentally do this by blocking the main thread. They'd even give visual feedback - the button remains looking pressed until the click handler returns when the operation is complete! Maybe blocking the main thread isn't so bad after all?
It might be quite a hard problem to determine which buttons should be disabled during which operations. One tricky candidate is the "safe" button. Should I be able to click it when the visual feedback I'm getting does not yet match the internal state of the application (which is what will be saved)? Should I be able to start further tasks when the save is still in progress? (If so, what if the save fails? Will I be able to roll back to the state before the attempted save and try again?)
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…
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. It will, at which point the dev will try it again, and it will probably work the second time, so they can stop thinking about it.
There was a big outbox pattern discussion a couple of days ago (split thing 1 into two halves, and do them atomically, leave thing 2 as an exercise for the reader.)
I think the reason you encounter this problem in the real world is that devs just exist in some quantum superposition of "it won't happen" and "I fixed it" and "it can't be fixed".
Reminds me of the time I built a BabyButton, which was built in a way so that a baby could use it. Instead of the normal click behaviour, it was using the touchdown event, because that way the kid saw that something happened, and there was no problem with holding the button too long or moving the finger while still holding the button. Whether you should build systems for that age group is an entirely different topic,…
IRL 99%+ of buttons work by just doing the thing as soon as you press them. But a button that works like that in a GUI would feel wrong.
Earlier quoted context omitted.
I wish software apps had "tape-out rules" the way that computer chips do. Basically, when you design a computer chip, a program reviews the design and compares it against something like 300 pages of rules with stuff like "wires of X metal and Y metal can't be within Z distance of each other". We could make something similar for UX. Just a bunch of design pattern constraints that throw flags if you try to ship somethi…
There’s effectively no universal list of UX warts people agree with. The Flat UX fad was objectively terrible on just about every metric I was taught, but people were actively pushing for such designs.
Although in 3.1 it was easy to tell what was interactable, despite being flat. I attribute this to the use of standardized components almost everywhere.
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.
This is a somewhat unpopular opinion here, however I do think flat UI can be done right and is well fitted to digital UIs. It's possible to have a flat style but have buttons that look clearly like buttons, and elements that have shadows and colors.
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 just because I grew up with that) but it wasn't unusable at all. As you say, it was clear what was a button, what was a checkbox. I think it was because GUIs were mostly made out of standardized elements whereas today we have everyone trying to put their unique spin on every element.
When they're off, they don't blow any air so it would make sense to me to decide that the button to turn them on is the one that controls how much air it blows. It goes from 0 to 1 to turn on, so you just learned that that button changes how much air comes out of it.
But no, most of them do the opposite. So, you turn them on with the temperature control. The action is: no air, yes air, air gets super-hot if you keep pushing the button.
I can't find any modern air dryers where they get this right.
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…
They didn't say how often the reads are - 50 reads could be only 5ms.
An averaging filter makes sense if you have a noisy analog input. For a button input that registers whether it is pressed or not except for a known noise around transitions specifically, ignoring the transitions immediately after the first one registered is not only faster (both in terms of latency and CPU cost) but easier to implement. It's also equally practical for switches with long bounce, where the time it would take for an average to favor a transition might be impractically long.